Moje mesto na webu
Google ne prestaje da me oduševljava sa novim i zanimljivim servisima. Ovog puta radi se o servisu Google Trends koji analizira broj upita za određenim pojmom koji su izvršeni na Google-ovom sajtu u određenom vremenu. Rezultat analize dobijate grafički, a pored analize pretraživanja tu je i grafik koji prikazuje frekvenciju pojavljivanja unetog pojma u vestima. Impresivno je posmatrati šta se dešava kada unesete dva ili više pojmova… Ja sam ovom prilikom uneo Imena Zidana i Ronaldinja i evo šta sam dobio.
Nije loše za neke analize, naročito što su špicevi u pretragama pojašnjeni vestima koje su vezane za dati pojam. U svakom slučaju probajte…
Template patern se koristi kada uočite da istim algoritmom možete rešiti različite specifične probleme. Template patern znači definiše korake u algoritmu i omogućava podklasama da obezbede implementaciju za jedan ili više koraka.
Template patern se zasniva na jednoj apstraktnoj klasi u kojoj postoji Template metoda u okviru koje su definisani koraci algoritma. Može postojati veliki broj konkretnih klasa koje nasledjuju ovu apstraktnu klasu i koje implementiraju njene apstraktne metode, dajuću na taj način već definisanom alogritmu novu funkcionalnost.
U okviru Template paterna uvodi se jos jedan princip dobrog dizajna:
Suština Holivudskog principa je da se obezbedi da komponente “višeg nivoa” ne zavise od komponenti na nižem nivou. Ovo se ostvaruje tako što komponenta na višem nivou može da koristi usluge komponenti nižeg nivoa ali samo kada za tim postoji potreba. Takođe dobro je obezbediti da komponente nižeg nivoa nikada direktno ne pozivaju komponentu višeg nivoa.
Komponenta “višeg nivoa” kod Template paterna je apstraktna klasa odnosno metoda u kojoj je definisan algoritam. Konkretne klase i njihove metode su te koje će biti pozivane po potrebi kada aloritam za tim bude imao potrebu.
Holivudski princip pored Template paterna koriste i Observer i Factory patern.
Koristeći objektno orjentisani pristup za razvoj CMS sistema koji koristimo u firmi SDStudio, umnogome se olakšalo održavanje koda i povećala čitljivost. Medjutim performanse su te koje trpe. Jednostavno praksa je pokazala da se objektno orjentisani kod ipak sporije izvršava od istog koda koji je napisan proceduralno. Proceduralni kod je sada prevazidjen iako ga PHP 4.x koristi ipak je sasvim moguće pomoću i ove starije verzije pisati aplikacije u OOP maniru. Razlike koje se ostvarju u čistoći koda su ogromne. Još kada se svemu doda ORM (Object Relational Mapper), zatim paterni, ali i Templejt sistem (Smarty) produktivnost drastično raste.
Ali uvek postoji trade off, sva ta lakoća i uživanje koje se ostvaruje sa OOP i skoro potpuna rasterećenost da se pišu bilo kakvi SQL upiti osim onih malo složenijih (sa INNER i LEFT JOIN-ovima, ostvarena pomoću ORM-a) došao sam u situaciju da ipak moram optimizovati izvršenje koda ili bar naći način da keširam već generisane stranice na serveru i da ih kao takve (ako se u medjuvremenu nisu menjale) šaljem korisnicima.
Keširanje php stranica
Ideja koja je već odavno prisutna je da se keširaju stranice koje se inače dinamički generišu svakim pozivom. šta ovo tačno znači. Pa pozivom odredjene stranice koja ima u sebi uvezan dinamički sadržaj, poziva se php kod koji se zatim izvršava. U okviru ovog izvršenja može se desiti da bude uključeno više desetina raznih drugih php fajlova, sa funkcijama, definicijama klasa itd. Ne smemo nikako zanemariti i SQL upite koji se izvršavaju a kojih može biti takodje jako puno, a samo da bi se jedna jedina stranica izgenerisala. Obzirom da će se sadržaj menjati ipak relativno retko, ukoliko se radi o nekom običnom sajtu … nije potrebno da se svakim pozivom izvršava gomila komplikovanog PHP i SQL koda, već je dovoljno dobro da snimimo izgenerisani dinamički sadržaj stranice u neki fajl (isto kao statične html stranice) i da to pošaljemo direktno klijentu bez ikakve dodatne obrade na serveru. Na ovaj način klijent će imati poboljšan user-experience, a server će biti rasterećen nepotrebne obrade.
Kako još uvek nisam implementirao sistem za keširanje za CMS sistem koji razvijam odamah želim da napomenem da ovde nećete naći tutorial kako da to uradite. Ovde će biti postavljeno samo razmatranje načina kako da se keširanje što efikasnije primeni na nečemu što već razvijate.
Cache Lite
Moj izbor, gledajući dokumentaciju i sajtove koji se bave ovom tematikom je pao na Cache_Lite koji predstavlja deo PEAR bibloteke.Cache_Lite je optimizovan za sajtove sa velikim obimom saobraćaja i veoma je brz ali i siguran jer podržava i zaključavanje fajlova.
Problem koji vidim da će možda nastati vezan je za integraciju cache_lite-a sa Smarty template engine-om. Više o svemu kada implementiram keširanje u CMS.
Eh da imam para za ovo.... RT @vuglll prodajem iPad 32 GB 3G + WiFi + camera connection kit, nov neotpakovan, donet iz USA - 750 EUR #