Do dzisiaj pamiętam jak po raz pierwszy miałem okazje zobaczyć jak to naprawdę wygląda. Były to gogle Virtual Boy dla Nintendo - i chociaż grafika nie była jak na dzisiejsze standardy wysokich lotów, to uczucie było niesamowite. Pomijam milczeniem fakt, że po niespełna 30 minutach używania tego cuda miało się nieodpartą chęć uściskania toalety i zwrócenia wszystkiego co się zjadło

Czas jednak płynął, hełmy wirtualne nadal były tylko życzeniem pod choinkę, każdego zapalonego gracza.

Obecnie, mimo ogromnej mocy obliczeniowej i zapierającej dech w piersiach grafiki 3d, nadal nie ma co marzyć o pełnym zagłębieniu się w wirtualny świat przy pomocy takich gogli.

Być może nadal problemem jest cena, a co za tym idzie niski popyta na takie akcesoria, a co za tym idzie bardzo mała ilość oprogramowania wspierającego tą technologię, ale na przeciw temu wysuwa się ostatnimi czasy inna, równie ciekawa technologia – Rozszerzona Rzeczywistość (Augment Reality).

AR jest to w skrócie technologia pozwalająca na połączenie świata rzeczywistego z tym wygenerowanym komputerowo.

Powiedzmy, że stoimy w muzeum przed pięknym obrazem autorstwa… no właśnie kogo? Podpis pod obrazem jest za mały abyśmy mogli go odczytać, a masa ludzi nie ułatwi nam podejścia do niego. W takim przypadku możemy skorzystać z AR. Zakładamy nasze okulary, które dzięki kamerom umieszczonym na nich skanują to co widzimy. Oprogramowanie rozpoznaje obraz i na wyświetlaczu w szkłach naszych okularów, prezentuje nam informacje o obrazie.

Dzięki oprogramowaniu możemy także tworzyć wirtualne obiekty, które wchodzą w interakcje z otoczeniem. System sam tworzy sobie siatkę geometryczną widzianej przez nas przestrzeni i kieruje obiektami tak aby te przy np. zderzeniu ze ścianą zachowały się naturalnie – jak prawdziwe obiekty.

Gdyby dodać do tego jeszcze rękawice z force feedbackiem, takie jak chociażby oferowane przez firmę Immersion uczucie zanurzenia w wirtualną rzeczywistość było by większe niż w przypadku wirtualnych gogli.

Tyle słowem wstępu, a teraz zapraszam Was do obejrzenia AR w akcji:

Przykład aplikacji na iPhonea:

http://www.youtube.com/watch?v=tpaJBu4BEuA

Obiekty 3d w realnym świecie:

http://www.youtube.com/watch?v=yAvR2dJvZCc

Przykład tego jak AR może pomóc lekarzom:

http://www.youtube.com/watch?v=vgCDTPqAj2E

Dzięki temu bez potrzeby czytania całego opisu wiemy w co kliknąć.

Postęp technologiczny sprawia jednak, że część ikonek zaczyna tracić sens i przestaje być zrozumiała dla młodego odbiorcy.

Zwróćmy uwagę na poniższą listę ikonek:

„Zapisz” prezentowane jako dyskietka.

„Filmy” prezentowane jako klisza filmowa.

„Szukaj” prezentowane jako lupa (szkło powiększające).

Wszystkie te znaki graficzne choć zrozumiałe dla starszego pokolenia i ludzi często przesiadających przed komputerem, dla młodszych osób mogą już nie być tak oczywiste.

Kto w dzisiejszych czasach używa dyskietek do przechowywania danych? Współczesne komputery zaczynają być pozbawiane stacji dyskietek, a więc czemu ten piktogram miał by nam się kojarzyć z „zapisywaniem”?

Lupa także jest rzeczą, która obecnie rzadko kiedy jest wykorzystywana – w dobie internetu i książek wydawanych elektronicznie, młode pokolenie rzadko ma z nią styczność.

Przedstawianie filmów jako rolki taśmy filmowej było dobre za czasów VHSów (chociaż i utaj taśma wyglądała nieco inaczej). Ale dzisiaj kiedy nawet w kamerach dane zapisuje się na płytach, dyskach czy pamięciach flash taka wizualna identyfikacja już traci na znaczeniu – to tak jakbyśmy ikonkę „Mój komputer” zaprezentowali jako pancerną szafę w której znajdowały się wczesne komputery.

Sądzę, że projektanci aplikacji/stron powinni już teraz pomyśleć nad tym aby odświeżyć ikonki tak aby ich znaczenie było aktualne i zrozumiałe w dzisiejszych czasach, bez potrzeby sięgania do podręcznika historii

Najlepiej zacząć wszystko unifikować. Tworzyć kod ogólnego użytku, tworzyć warstwę-warstwy-warstwy pośredniej, używać wielu klas abstrakcyjnych, przewidywać możliwe sposoby użycia dla wręcz paranoicznych przypadków. Poddać się naszej chęci do stworzenia kodu wręcz doskonałego. Kodu gotowego do zastosowania dla pierwotnej idei ale także do nieco bardziej rozbudowanych funkcji, a może i nawet do funkcjonalności której ten kod nie został z początku pomyślany… a dlaczego nie miał by on parzyć kawy i wyrzucania śmieci – w końcu skąd mamy wiedzieć czy docelowo do tego go nie użyjemy?

Jednym słowem najlepiej stworzyć kod, którego sam Bóg by się nie powstydził, a po naszej śmierci (jak to zwykle bywa z tego typu honorami) postawiono by nam pomnik w dowód naszego wkładu w budowanie lepszego świata.

Ale zacznijmy od początku.

W swojej pracy i poza nią spotkałem się z dwoma głównymi typami programistów, pod opisami którymi, mniej lub bardziej każdy z nas może się podpisać.

Pierwsza grupa to zadaniowcy. Programiści, którzy pracują nad projektem od zadania, do zadania. Rozwiązując na bieżąco problemy, które napotkają. Nie wnikając zbytnio w atomowe części projektu i skupiający się na uzyskaniu założonego celu.

Druga grupa to artyści. Programiści, którzy mają wizję i często dają się jej ponieść. A wtedy już nie trudno o to aby projekt stał się kolejną częścią koszmaru z ulicy wiązów.
Niestety często mogę podpisać się pod tą druga definicją.

Nie tak dawno wraz z kolegą omawialiśmy pewien projekt. Siedząc przy piwku sporządzaliśmy zestaw wymagań tego co ta aplikacja ma posiadać.

Wyszliśmy z podstawowego celu jakim była założona funkcjonalność, ale szybko doszliśmy do wniosku, że może się ona rozszerzyć o kilka innych, których powiązanie może nie do końca współgrać z tym co ustaliliśmy (a przynajmniej tak sobie wmawialiśmy).

Zaczęliśmy więc kombinować i rozbudowywać funkcjonalność kierując się zasadą uniwersalnego rozwiązania, które w przyszłości będzie na tyle elastyczne, że nie będziemy mieli problemów z jakąkolwiek modyfikacją…

Po ponad 1h doszliśmy wspólnie do jednego wniosku: dzięki naszemu rozwiązaniu pozycja obecnych systemów operacyjnych jest zagrożona. Czemu ? Bo oto wymyśliliśmy rozwiązanie, które z powodzeniem posłuży jako podwaliny pod nasz projekt ale z równym powodzeniem można by go użyć do budowy systemu operacyjnego.

(nawiasem mówiąc przypomina mi się projekt Thot tworzony na php.pl )

Zapewne przed emeryturą byśmy go skończyli ale jak wiadomo zapał programistów maleje wykładniczo do funkcji czasu. A przecież sam projekt zapowiadał się na prostą aplikację na góra 2 miesiące roboty.

Popłynęliśmy. Mając jednak tą świadomość zeszliśmy na właściwy tor.

Takie podejście w porę niezauważone i pielęgnowane przez developerów jest powodem dla którego nie jeden dobrze zapowiadający się projekt zostaje z czasem pogrzebany w lawinie funkcjonalności.

A rozwiązanie jest bardzo proste: należy skupić się wyłącznie na określonej funkcjonalności. Trzeba precyzyjnie określić ramy działania aplikacji i oczekiwania wobec nich. Myśląc o przyszłości i konieczności rozbudowania aplikacji zawsze warto najpierw zastanowić się czy obecna funkcjonalność jest na tyle hermetyczna, że nic się z nią nie da później zrobić – przy odpowiednio pisanym kodzie (korzystając z wzorców projektowych) zawsze znajdzie się jakieś pole do zmian i nie trzeba z góry zakładać, że potrzebna jest nam kolejna abstrakcyjna warstwa już na początku etapu pisania kodu.

Projekt trzeba tworzyć w myśl zasady KISS (keep it simple stupid). Budować projekt klocek po klocku. Oczywiście z zachowaniem zasad OOP. Przerost formy nad treścią w końcowym rezultacie może doprowadzić do zakończenia projektu totalna klapą albo sytuacją w której będziemy mieli uniwersalne środowisko (framework) do którego dopiero zaczniemy dopisywać docelową funkcjonalność.

Myślę, że dobrym porównaniem było by stworzenie przez Microsoft Visty zamiast DOSa. W końcu czemu mieli by się ograniczać do zwykłej linii komend skoro mogą zrobić od razu coś wielkiego.

Reasumując: tym postem chciałem tylko zaznaczyć pewien problem który wielu z nas zapewne już przeszło, są w jego trakcie albo dopiero się z nim zmierzy. Z mojego doświadczenia mogę doradzić tylko jedno: lepiej w porę przystopować i starać się zajmować podstawową funkcjonalnością – nie jest to oznaką braku inwencji, a jedynie rozsądnym podejściem do pisania programów.

Czekam na komentarze i Wasze spostrzeżenia w tym temacie

moBlog to serwis społecznościowy skupiony wokół marki Nokia i udostępniający swoim użytkownikom platformę blogową dostępną przez WWW jak i telefon komórkowy…

No dobra… dosyć tej marketingowej gadki

Powody dla których chciał bym Wam nieco przybliżyć ten serwis są dwa: współtworzę ten serwis od czasu powstania nowej wersji (pierwsza wersja powstała ponad 2 lata temu) oraz dlatego, że jest to bardzo ciekawa alternatywa dla innych tego typu stron.

Głównym kanałem publikacji wpisów na blogach są MMSy. Chociaż ta forma komunikacji jest wykorzystywana w innych serwisach to na moBlogu jest ona dominującą funkcjonalnością – nie ma możliwości dodania zdjęcia w inny sposób niż po przez MMS lub aplikację LifeBlog z telefonu komórkowego. Mimo dostępnej opcji dodania wpisu tekstowego z poziomu strony WWW, tylko wpisy MMSowe są promowane umieszczeniem na stronie głównej.

I tutaj mała uwaga: z moich obserwacji wynika, że takie podejście sprawia iż pewne grono osób zakładających tzw. „bLoGaSkI” już na wstępie jest filtrowana. Powód jest prozaiczny: kasa. Wydanie kilku groszy na MMSa powoduje że prędzej czy później osoba taka rezygnuje.

Pomijając ten fakt warto zaznaczyć, że w dobie komunikacji obrazkowej ludzie chętniej oglądają ładne zdjęcia niż zagłębiają się w dwu stronicowe wywody o tym jaki świat jest okrutny

Wracając do funkcjonalności: wysłane MMSy można edytować z poziomu WWW po przez dodawanie/edycję tekstu i tematu, przypisywanie tagów do wpisu, przypisanie do galerii, ustawianie położenia na mapie czy też edycję samego zdjęcia.

Warto zaznaczyć, że użytkownicy już na etapie wysyłania MMSa mają możliwość skorzystania z komend MMSowych umożliwiających im umieszczenie wpisu od razu w wybranej przez nich galerii, przesłania wpisu znajomemu na email czy też ustawienia lokalizacji na mapie.

Nie zapomnieliśmy o prywatności dlatego też galerie mogą mieć status publiczny, tylko dla znajomych lub na hasło.

To co zwiększa atrakcyjność tego serwisu to możliwość prawie nieograniczonej modyfikacji wyglądu. Począwszy od położenia i widoczności boxów, po przez edycję skórki i umieszczania elementów zaciąganych z zewnętrznych serwisów (YouTube, LastFM, Grono).

W porównaniu z innym serwisami edycja skórek nie odbywa się po przez ręczne wklepywanie kodów kolorów czy edycję HTMLa, a po przez wizualny edytor umożliwiający nawet laikowi stworzenie własnego niepowtarzalnego wyglądu (także na bazie udostępnionych przez nas skórek publicznych).

W niedawno udostępnionej aktualizacji wprowadziliśmy także możliwość udostępniania skórek (po wcześniejszej akceptacji moderatorów) innym użytkownikom.

Dodam jeszcze, że przy każdej ze skórek wyświetlany jest jej podgląd w postaci miniaturki, generowanej z naszej autorskiej aplikacji do tworzenia zrzutów stron WWW.

Wspomniana przeze mnie wcześniej geolokalizacja wpisów na mapie wykorzystuje mapy Google. Poza lokalizowaniem na mapie wpisów mamy także możliwość ustawienia własnej lokalizacji. Dzięki globalnej mapce mamy możliwość podglądu miejsc do których zostały przypisane wpisy, a także ostatnio zalogowanych osób.

Oczywiście nie zabrakło także funkcjonalności czysto społecznościowych takich jak lista znajomych, lista ulubionych moBlogów, prywatne wiadomości czy grupy dyskusyjne tworzone przez użytkowników.

Całość spaja rozbudowana wyszukiwarka umożliwiająca przeszukanie moBloga po prawie wszystkich danych jakie użytkownik udostępnił publicznie na swojej stronie.

To co opisałem to tylko najważniejsze elementy funkcjonalne moBloga, a zapewniam Was, że jest jeszcze więcej innych ciekawych opcji.

Podsumowując tą małą krypto reklamę dodam, że moBloga napisany został w… PHP.

Mimo, że nie mogę zdradzić szczegółów to po samej ilości użytkowników i wpisów możecie stwierdzić, że obciążenie serwisu nie jest małe, a baza danych nie mieści się na jednej dyskietce

Może więc da to trochę do myślenia niedowiarkom, którzy twierdzą że PHP nie nadaje się do poważniejszych zastosowań.

When accessing a web control from design mode you’ve probably seen a Font property. This property has a sub property Name which lists all fonts in a sexy drop down list.

Those font properties are made by FontInfo class which you can freely use in your control. But if you would like to grab only Name sub property of FileInfo for your control the horror begins.

But here is the solution

( ...)
[Editor("System.Drawing.Design.FontNameEditor, System.Drawing.Design", typeof(System.Drawing.Design.UITypeEditor))]
[TypeConverter(typeof(System.Drawing.FontConverter.FontNameConverter))]
public string FontName
{
(...)
}
(...)

Adding Editor and TypeConverter makes all magic. After that you can see a property with lovely fonts list

This little trick I’ve found thanks to… Open Source and implementation of FileInfo in Mono project.

Hope this help you save a time

SELECT

Proste pobieranie rekordu po kluczy głównym:

$rekord = Doctrine::getTable('DoctrinowaNazwaTabeli')->find($idRekordu);

Inna postać powyższego przykładu:

$rekord = Doctrine_Query::create()
->from('DoctrinowaNazwaTabeli dnt')
->where('dnt.id_tabeli = ?', $idRekordu)
->limit(1)
->execute()
->getFirst();

W powyższym przykładzie mogli byśmy jeszcze dodać po create()->select() ale w przypadku pobierania rekordu w postaci obiektów nie używa się tego. O innej metodzie zwracania wyników napisałem kilka pięter niżej

W sekcji WHERE w pierwszej wartości podajemy warunek. W miejsce znaku zapytania wstawiona zostanie wartość podana po przecinku. W przypadku gdy chcemy zastąpić więcej niż jeden znak zapytania, odpowiednimi wartościami, musimy listę zmiennych umieścić w postaci tablicy:

$rekord = Doctrine_Query::create()
->from('DoctrinowaNazwaTabeli dnt')
->where('dnt.id_tabeli = ? AND dnt.name = ?', array($idRekordu, $nazwa))
->limit(1)
->execute()
->getFirst();

Zmienne są automatycznie odśmiecane, więc nie musimy się o to martwić.
Zwróćcie także uwagę na to, że w sekcji FROM obok „doctrinowej” nazwy tabeli, po spacji dodajemy alias dla tej tabeli. Jest to dowolny ciąg znaków (chociaż ja przyjmuje zawsze pierwsze litery z cammel-caseowej nazwy), który później posłuży nam do odwoływania się do nazw kolumn w tej tabeli.

To na co jeszcze warto zwrócić uwagę, to metody execute() oraz getFirst().
execute() wywołuje nam całe zapytanie i zwraca obiekt Doctrine_Collection zawierający zwrócone rekordy. Jest to kolekcja obiektów, a więc możemy spokojnie użyć pętli foreach aby pobrać każdy z rekordów (który w naszym przypadku będzie instancją klasy DoctrinowaNazwaTabeli).
getFirst() służy do pobrania z kolekcji zwróconej przez execute() tylko jednego (pierwszego) rekordu.

I tutaj mała uwaga: nawet jeżeli zapytanie nie zwróci żadnych rekordów to execute() i tak zwróci kolekcje Doctrine_Collection. Będzie ona jednak pusta. Dlatego warunek w stylu if ($wynik) zawsze zwróci true. W tym przypadku należy więc użyć if (count($wynik) > 0).
Natomiast korzystając z metody getFirst() otrzymamy albo rekord, albo wartość null – i tutaj powyższy pierwszy IF zadziała.

Wracając jeszcze do metody execute() warto zaznaczyć, że możemy w niej wykonać dwie rzeczy: przekazać listę parametrów które mają zastąpić znaki zapytania oraz podać typ w jakim mają zostać zwrócone wyniki.

Listę parametrów podajemy zawsze w postaci tablicy, a typ zwracanych danych jest stałą dostępną w klasie Doctrine.

$rekord = Doctrine_Query::create()
->from('DoctrinowaNazwaTabeli dnt')
->where('dnt.id_tabeli = ? AND dnt.name = ?')
->limit(1)
->execute(array($idRekordu, $nazwa), Doctrine::FETCH_ARRAY)
->getFirst();

Przekazując zmienne w execute() nie podajemy ich już w where(). Dodatkowo jeżeli chcemy tylko ustawić typ zwracanych danych listę parametró∑ zostawiamy jako pustą tablicę:

$rekord = Doctrine_Query::create()
->from('DoctrinowaNazwaTabeli dnt')
->where('dnt.id_tabeli = ? AND dnt.name = ?', array($idRekordu, $nazwa))
->limit(1)
->execute(array(), Doctrine::FETCH_ARRAY)
->getFirst();

Dzięki Doctrinowi możemy także pobrać powiązane rekordy:

echo $rekord->PowiazanaTabela->nazwa;

Doctrine sam wykona odpowiednie zapytanie pobierając powiązany rekord – metoda ta nazywa się lazy-loading.

Aby zapobiec każdorazowemu pobieraniu pojedyńczych powiązanych rekordów możemy pobrać je za jednym zamachem stosując konstrukcję * JOIN.
W Doctrine wygląda to w ten sposób:

$rekord = Doctrine_Query::create()
->from('DoctrinowaNazwaTabeli dnt')
->innerJoin('dnt.PowiazanaTabela pt')
->where('dnt.id_tabeli = ? AND dnt.name = ?', array($idRekordu, $nazwa))
->limit(1)
->execute(array(), Doctrine::FETCH_ARRAY)
->getFirst();

Do metody innerJoin() przekazujemy co chcemy pobrać podając następujące dane:
- nazwa aliasu tabeli głównej
- kropka
- „doctrinowa” nazwa tabeli powiązanej z główną
- po spacji podajemy alias dla powiązanej tabeli.

Poza innerJoin() możemy też użyć innych metod jak chociażby leftJoin(), rightJoin() – szczegóły w dokumentacji

UPDATE

Update można zrealizować na dwa sposoby.

Po przez aktualizacje aktualnie używanego obiektu metodą save() na tym obiekcie:

$rekord->nazwa = 'Test';
$rekord->email = 'test@example.org'
$rekord->save();

I jeszcez nieco bardziej skomplikowany UPDATE aktualizujący od razu powiązany rekord:

$rekord->PowiazanaTabela->nazwa = 'Testing';
$rekord->PowiazanaTabela->ala_ma_kota = true;
$rekord->nazwa = 'Test';
$rekord->email = 'test@example.org'
$rekord->save();

Można też skorzystać z takiej oto metody:

Doctrine_Query::create()
->update('DoctrinowaNazwaTabeli dnt')
->set('dnt.nazwa', 'Test')
->set('dnt.email', 'test@example.org')
->where('dnt.id_tabeli = ?', $idRekordu)
->execute();

Przykład jest jasny, więc nie będę go opisywał.

INSERT

Dodawanie rekordów jest równie proste co pobieranie danych i ich aktualizacja.

Aby utworzyć nowy rekord wystarczy stworzyć nowy obiekt klasy tabeli:

$rekord = new DoctrinowaNazwaTabeli();
$rekord->nazwa = 'Abc';
$rekord->email = 'test2@example.org';
$rekord->save();

Metoda save() wstawi za nas rekord do bazy.
Uprzedzam pytanie: nie ma możliwości wstawienia rekordu inną metodą jak w przypadku SELECT czy UPDATE.

DELETE

Usuwanie rekordów wykonuje się dwoma metodami tak jak w przypadku UPDATEa.

Mając już pobrany rekord w postaci obiektu, wystarczy że wykonamy na nim metodę delete():

$rekord->delete();

Lub też zbudujemy sobie zapytanie:

Doctrine_Query::create()
->delete()
->from('DoctrinowaNazwaTabeli dnt')
->where('dnt.id_tabeli = ?', $idRekordu)
->execute();

Jednak ZF to tak naprawdę zbiór klas. Coś na kształt .NET’a (nie ASP.NET, a sam .NET Framework) czy też, nie szukając zbyt daleko, eZ Components. Takie podejście ma zdecydowanie swoje plusy, jednak posiada zasadniczą wadę. Jeżeli spojrzymy na to z punktu widzenia programisty, który siada do projektu i ma przed sobą kilka mniej lub bardziej przydatnych rozwiązań, luźno ze sobą związanych, to można sobie zadać pytanie czy ZF nie zabierze nam za dużo czasu przy lepieniu całości? Czy nie lepiej wybrać inny framework jak np Symfony, CakePHP, Prado etc? Frameworków opartych o zasadę out-of-the-box.

Zważywszy na to, że dokumentacja czasami jest niekompletna, przebicie się przez nią i stworzenie szkieletu ZF dla strony WWW zabiera trochę czasu. Czasu, który moglibyśmy spożytkować na kodowanie funkcjonalności docelowej strony.

Przy pierwszych wersjach ZF oznaczonych jeszcze numerkiem 0.x starałem się przymykać oko na to, że aby rozpocząć pracę muszę w pierw przygotować sobie całe środowisko. Pododawać klasy do obsługi MVC, stworzyć niezbędne katalogi, skonfigurować front-controller etc. Jednak w wersjach 1.x nic się w tej materii nie ruszyło. Dodatkowo dokumentacja nie oddawła pełnych możliwości i opcji jakimi dysponuje ZF. Nadal brak było (i jest ) szkieletu dla aplikacji webowych – mówię tu o gotowym rozwiązaniu, które pozwalało by po prostu na to aby wpisać dane dostępowe do bazy, dodać HTMLa w odpowiednim miejscu i akcje do operowania na danych.

Dlatego właśnie moją uwagę bardziej przykuwają rozwiązania takie jak Symfony czy Prado.

Niestety jednak ZF nie daje mi spokoju Jest on zdecydowanie szybszy niż rozwiązania konkurencji, właśnie ze względu na swoją prostotę i to, że wykorzystuje on niezbędne minimum do działania.

Kiedy usłyszałem o ZF 1.5 i w końcu (!!!) dodanemu Zend_Layout, zmotywowało mnie to do przygotowania małego szkieletu ZF, tak aby na jego podstawie móc tworzyć mniej lub bardziej skomplikowane rozwiązania.

W krótcę podeślę na bloga paczkę ze szkieletem ZF, który mam nadzieję pomoże nieco w konstruowaniu strony opartych na ZF.

W założeniach będzie to bardzo minimalistyczny szkielet:

• predefiniowany layout katalogów,
• struktura modułowa,
• predefiniowane pliki konfiguracyjne w postaci XMLa (albo YAML jeżeli będę miał czas napisać do tego klasy) – ustawienia bazy danych, routingu etc.,
• Doctrine jako warstwa dostępu do bazy danych,
  • + implementacja logowania zdarzeń oraz autoryzacji w oparciu o Doctrinea – Zend_Log_Writer_DB oraz Zend_Auth_Adapter_DbTable z wykorzystaniem Doctrine.

Czyli totalne minimum aby móc zacząć pracę bez potrzeby zagłębiania się w szczegóły konfiguracji modelu MVC w Zend Framework.

Jeżeli macie jakieś propozycje co do tego co mogło by się tam znaleźć zapraszam do dyskusji

Chłopaki dali z siebie dużo serca i trzeba przyznać, że efekt końcowy jest rewelacyjny

Szczególnej uwadze polecam podstronę http://k2.pl/case_moblog.html jako, że mocno maczałem w tym projekcie palce

Na przeciw temu powstawały biblioteki „abstrakcyjnego” dostępu do baz danych – DAO (Data Access Object) – nazywane także warstwą pośrednią dostępu do danych.

Niewątpliwie takie podejście pozwoliło, przynajmniej w teorii, odetchnąć z ulgą w przypadku gdy musieliśmy zmienić bazę na inną niż dotychczas używaną.

Świat na szczęście nie stoi w miejscu i doczekaliśmy się rozwiązań dla leniuchów

Mówię tu o tzw. ORM’ach – Object-Relational Mapping. Jest to w skrócie technika umożliwiająca mapowanie danych do postaci obiektów, które w prosty i łatwy sposób możemy wykorzystywać w aplikacji. Dzięki niej, nie musimy także pisać SQLa przez co raz, że skraca się czas tworzenia aplikacji, a dwa zmniejsza ilość błędów – w tym zapobiega atakom SQL Injection.

I właśnie o jednej z implementacji ORM’ów chciał bym tutaj napisać.

Doctrine, bo o niego mi chodzi, to implementacja ORM’a rodem z Javy i jej Hibernate’a. Tak jak i on posiada swóją własną abstrakcyjną warstwę dostępu do danych i wewnętrzny język SQLowy zwany DQL – „obiektowy” SQL.

Oczywiście jego głównym zadaniem jest mapowanie danych do postaci obiektów. Dzięki temu w prosty sposób mam dostęp do naszych danych.

Nie będę opisywał szczegółów działania czy procedury instalacyjnej i konfiguracyjnej tego środiwska, ale chciał bym przedstawić Wam tylko kilka przykładów w jaki sposób wygląda dostęp do bazy przy użyciu Doctrine’a. Niestety w polskiej sieci mało jest informacji o tej bibliotece, a jest to w mojej ocenie jeden z lepszych produktów dla PHP, którym warto się zainteresować.

Zobaczmy więc przykładowe wywołanie zapytania INSERT:

$user = new User();
$user->name = 'Jan';
 
$user->surname = 'Kowalski';
 
$user->save();

…i tyle Oczywiście klasę User zdefiniowaliśmy wcześniej zgodnie z wytycznymi jakie zawarte są w dokumentacji Doctrine’a.

Powyższy kod w bardzo prosty sposób wstawia rekord do tabeli z użytkownikami. Jak widać w ogóle nie użyliśmy SQL’a.

Kolejnym przykładem jest dostęp do powiązanej z tabeli profile, powiązanej z tabelą user.

echo $user->Profile->hobby;

Kod ten ma za zadanie pobranie z tabeli profile, kolumny hobby. Tabela profile, jest powiązana z tabelą user, co zdefiniowane zostało w konfiguracji tej tabeli.

Taki zapis jest tym samym co wykonanie zapytania:

SELECT hobby FROM profile WHERE id_user = xxx

Jednak doctrine sam zajmie się skonstruowaniem zapytania tak abyśmy nie musieli się tym zajmować.

Przyjrzyjmy się teraz nieco bardziej skomplikowanemu kodowi:

$users = new Doctrine_Query()->from('User u')
 
->innerJoin('u.Profile p')
 
->innerJoin('u.Group g')
 
->where('u.birthday = ?', 'now()')
 
->limit(5)
 
->execute();
 
foreach ($users as $user) {
 
   echo $user->name . '';
 
   echo $user->Group->name . '';
 
   echo $user->Profile->hobby . '
 
';
 
}

Na początku wykonujemy zapytanie które pobierze nam 5 użytkowników, którzy urodziny wypadają dzisiaj (zwróćcie uwagę na zapytanie WHERE, które zawiera znak ‘?’ – w jego miejsce wstawiona zostanie wartość ‘now()’. Gdyby była to inna wartość została by ona automatycznie oczyszczona ze znaków, które powodowały by błędy w zapytaniu SQL). Dodatkowo pobierzemy dane z dwóch powiązanych tabel profile oraz group. A na koniec wylistujemy wyniki.

Jak widać kod jest bardzo prosty i przejrzysty. Nie musieliśmy pisać żadnego SQL’a.

Przykład ten mogli byśmy także nieco okroić, przez usunięcie wywołań innerJoin(). W pętli foreach nie musielibyśmy nic zmieniać, gdyż Doctrine sam będzie wiedział co oznacza wywołanie $user->Group->name i zamieni je na pojedyńcze zapytanie SQL (metoda ta nazywa się lazy loading).

Przy tym przykładzie, wewnątrz pętli foreach moglibyśmy także zastosować metodę delete() na obiekcie $user, w celu usunięcia rekordu z bazy.

Doctrine oferuje oczywiście znacznie więcej jak np. wspomniany DQL, obsługę transakcji, własne triggery i sekwencje, obsługe drzewek SQLowych i wiele innych zaawansowanych rozwiązań. Dodatkowo warto wspomnieć iż Doctrine używa PDO, przez co jest to wydajne rozwiązanie. No i jak sami widzicie używanie go jest bardzo intuicyjne i nawet początkującemu nie powinno sprawić problemów.

Oczywiście są i inne tego typu rozwiązania jak chociażby Propel, Zend_Db, POG ale sądzę, że Doctrine już na tyle rozwiniętą biblioteką (i stale rozwijaną), że warto się nim zainteresować.

Więcej informacji o Doctrine dowiecie się z oficjalnej strony znajdującej się pod tym adresem:

http://www.phpdoctrine.org/

Czy jednak musimy korzystać tylko z naturalnych źródeł energii?

Otóż nie.

Jakiś czas temu władze miasta Vancouver wpadły na genialny pomysł. Otóż miasteczka olimpijskie, przygotowywane na olimpiadę zimową w 2010 roku będą ogrzewane z… ciepła pochodzącego z serwerowni.

Zasada jest niemalże identyczna jak przy wykorzystaniu ciepła pochodzącego z wnętrza ziemi (energia geotermalna). W tym przypadku będzie to jednak ciepło wytwarzane przez serwery.

Specjalne systemy mają odprowadzać ciepło i przekazywać je do systemów grzewczych budynku oraz do podgrzewania wody.

Trzeba przyznać, że pomysł jest bardzo rewolucyjny, a może raczej odważny, gdyż do tej pory serwerownie były raczej pożeraczami energii niż ich źródłami

Więcej informacji możecie przeczytać pod tymi linkami:

http://www.reuters.com/article/sportsNews/idUSN1830885620070419

http://www.city.vancouver.bc.ca/ctyclerk/newsreleases2007/NRneuFINAL.htm

http://greenlineblog.com/2010-olympic-village-using-sewage-heat-recovery/