Na mojem blogu, ki ga pišem v angleškem jeziku, pa lahko preberete še prispevek o tem kako sem sploh začel razvijat za Android platformo.

Prenesi

Screenshots

Tale članek sem se spravil pisat že dobro leto nazaj. Vmes sem tudi sformatiral disk in so šle stvari v tri … Kljub temu da je članek še vedno nedokončan sem se odločil da ga objavim, saj bo marsikomu v pomoč pri prvih korakih TDD-ja.

Prvi odziv programerjev ob omembi Test-Driven Developmenta je ponavadi negativen, saj pomislijo le na eno: “Tole mi bo pa vzelo dodatnih 50% več časa pri razvoju aplikacij.” Podoben odziv sem pred kratkim doživel pri “naših” programerjih, ko sem jim kazal kako naredimo “Acceptance Test” z uporabo Selenium RC-ja.^[1]
Zgornja trditev bi načeloma veljala samo če bi se življenski cikel aplikacije zaključil z prvo produkcijsko verzijo, ter ob klasičnem razvoju Dizajn-Implementacija-Testiranje^[2]. To zgodbo najverjetneje vsi poznamo:
“Imamo dva programerja, ki vsak zase nadgrajujeta svoj del že žive aplikacije. Ob združitvi kode, zgleda kot, da je vse ok. Čez čas dobita klic^[3], da določene stvari ne delajo, čeprav so prej delale. Vsak posebej za iskanje in razhroščevanje kode porabita polovico dneva.”
Take in podobne zgodbe so lahko preteklost. Rešitev je TDD.

Kaj je TDD

Test-Triven Development (TDD) je razvojna tehnika za softver. Z TDD tehniko stvari postavimo malce na “glavo”. Teste pišemo preden začnemo pisat implementacijsko kodo!. Test pelje oziroma diktira kodo ki se razvija.^[4]
TDD cikel pri razvoju aplikacij izgleda nekako takole:

• Dizajn: Pogruntamo kaj želimo narediti
• Test: Napišemo test, ki izraža naš dizajn.
  • Test ne bi smel uspeti – FAIL
• Implementacija: Napišemo kodo
• Test: ponovno
  • Test bi moral uspeti – PASS
• Refactoring po potrebi
• Ponavljaj

Še vedno vas je strah da bo več dela. Malce pa res. :)
Tri različne študije (Microsoft, IBM, John Deere / Ericsson) so pokazale:

• TDD projekti imajo dva krat večjo kvaliteto kode.
• Pisanje testov vzame le 15% več časa – dolgoročno gledano.
• Število hroščev in defektov je manjše za 40%.
• Skupinska produktivnost se poveča za 16%.

Testiranje

Kaj potrebuje testiranje?
- Backend: programska logika in ponovno uporabljene komponente
- Frontend: procesiranje form, templatov, bogata vsebina z uporabo “AJAX-a#, JSON, RSS Feed, Web Servisi

Kako testiramo?
- Backend: test funkcionalnosti programske logike z Unit Testi
- Frontend: “Acceptance” in Sistemski testi, ki se izvajajo na brskalniku, Testiranje RSS Feedov, Web servisov z Unit Testi, Kompatibilnostni testi …

Acceptance testing

je testiranje na določenem sistemu po principu “črne škatle“. Acceptance test zagotavlja da koda počna to kar želi “stranka”^[5], ne pa pričakovanj razvijalca! Temu testiranja bi lahko preprosto rekli tudi testiranje funkcionalnosti. Pa poglejmo kako implementirati Acceptance Test z “ubijalsko kombinacijo” PHPUnit in Selenium.

Priprave na testiranje

Zahteve:

• PHPUnit http://www.phpunit.de
• Testing_Selenium http://pear.php.net/package/Testing_Selenium
• Java 5 (1.5.0) je potrebna za Selenium RC http://java.sun.com
• Selenium Remote Control (RC) http://selenium.openqa.org/
• Xdebug^[6] če želimo informacije o “Code Coverage” http://www.xdebug.org

V tem članku uporabljamo PHPUnit, kateri od verzije 3.0 naprej, vsebuje PHPUnit_Extensions_SeleniumTestCase razred, katerega lahko uporabljamo za definicijo Acceptance testov. Sam razred pa za opravljanje testov potrebuje Selenium Core. Zelo pomembno je, da ne pozabimo da to NI Unit testiranje. PHPUnit je knjižnica za “Unit Testing”, med drugim pa je framework prav tako uporaben za integracijske ter acceptance teste.

Inštalacija PHPUnit:
Priročnik PHPUnit-a priporoča inštalacijo frameworka z uporabo PEAR Installer-ja. PEAR kanal (pear.phpunit.de), kateri se uporablja za distribucijo PHPUnit-a bora biti registriran z lokalnim PEAR okoljem.^[7] Ko to enkrat naredimo, uporabimo PEAR za inštalacijo paketa od PHPUnit kanala.

Inštalacija PHPUnita
PHPUnit dokumentacijo za Selenium najdete na http://www.phpunit.de/pocket_guide/3.2/en/selenium.html. Sedaj nam preostane še da iz PEAR kanala inštaliramo Testing_Selenium paket, ki ga potrebuje PHPUnit Selenium podaljšek.



Inštalacija paketa Testing_Selenium

Selenium:
je paket orodij za avtomatsko testiranje spletnih aplikacij. Vsebuje kar nekaj paketov, med drugim Selenium Core, Selenium RC, Selenium IDE, … Selenium Core opravlja aktivnosti uporabnika, izvaja test in obvešča o rezultatih testa. Selenium RC je dodatni serverski proces, ki ga rabimo, če želimo izvajati teste z PHPUnit podaljškom za Selenium. Njegov glavni namen je da omogoča izbranemu programskemu jeziku interakcijo z Selenium Core ki laufa na brskalniku z uporabo preprostega HTTP GET klica do RC strežnika. Komplicirano?!
Najnovejši Selenium RC dobite na http://selenium-rc.openqa.org/download.html. Po tem ko raspakiramo paket v njem najdemo kar nekaj map. V eni izmed njih je Selenium server, ostali so client driverji za različne programske jezike. Mi smo ga za PHP že inštalirali preko PEAR instalerja. Selenium RC zaženemo preprosto iz command lina:

java -jar selenium-server.jar -interactive

Še prej pa smo seveda inštalirali Javo. :)

Inštalacija Xdebug-a:
Xdebug je podaljšek za PHP, ki primarno služi za “debugging” – razhroščevanje kode, pri čemer je sposoben navrčt celo paleto koristnih informacij. Zna pa še narediti profil – “profiling” skripte in analizo pokritosti kode – “code coverage analysis”. Prav slednjo zadevo bomo pokazali v našem članku. Velja si zapomniti, da Xdebug ni potreben za izvajanje testov in da ga ne morete imeti naloženega skupaj z Zend Debuggerjem.
Najlažje je Xdebug inštalirati preko PEAR/PECL kanala.

pecl install xdebug

V php.ini dodamo tole klobaso^[8] za temeljit izpis informacij, remote debugging ter profiling na triger:

[Xdebug]
zend_extension="/opt/local/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so"
;General
xdebug.default_enable=On
xdebug.show_exception_trace=Off
xdebug.show_local_vars=1
xdebug.max_nesting_level=50
xdebug.var_display_max_data=3072
xdebug.var_display_max_depth=12
xdebug.dump_once=On
xdebug.dump_globals=On
xdebug.dump_undefined=On
xdebug.dump.REQUEST=*
xdebug.dump.SERVER=REQUEST_METHOD,REQUEST_URI,HTTP_USER_AGENT
xdebug.collect_params=4
xdebug.collect_includes=On
xdebug.collect_return=On
xdebug.show_mem_delta=On

;Remote debugging
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"

;Profiling
; Turns it off by default
xdebug.profiler_enable=0
; Turns xdebug on when ?XDEBUG_PROFILE=true is in GET or POST
xdebug.profiler_enable_trigger=1
; Your output directory - you'll eventually point webgrind at this
xdebug.profiler_output_dir="/tmp"

O samem orodju podrobno kdaj drugič. Gremo nazaj na testiranje.

Pisanje in zagon acceptance testov

Osnovna forma za acceptance test z PHPUnit in Selenium RC je zelo preprosta.

/** PHPUnit_Extensions_SeleniumTestCase */
require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class MonetaOrderTest extends PHPUnit_Extensions_SeleniumTestCase
{
    protected function setUp()
    {
        /**
         * '*firefox' => Firefox 1 or 2
         * '*iexplore' => Internet Explorer (all)
         * '*custom /path/to/browser/binary => Other browsers (incl. Firefox on Linux)
         * '*iehta' => Experimental Embedded IE
         * '*chrome' => Experimental Firefox profile
         */
        $this->setBrowser(*firefox /Applications/Firefox2.app/Contents/MacOS/firefox-bin);
        $this->setBrowserUrl(http://gateway.home.internet-solutions.si);
    }

    /**
     * Test if
     * label First Name exists
     * element firstName exists
     *
     */
    public function testFirstNameExists()
    {
        //open test/moneta
  	$this->open(http://gateway.home.internet-solutions.si/test/moneta');
  	/** First Name */
  	//label exist
        try {
            $this->assertEquals("First Name", $this->getText("//form[@id='moneta']/dl/dt[1]/label"));
        } catch (PHPUnit_Framework_AssertionFailedError $e) {
            array_push($this->verificationErrors, $e->toString());
        }
        //element present
        $this->assertTrue($this->isElementPresent("firstName"));
    }
}

Metoda setUp() se uporablja za “zagon” testa. Tukaj definiramo kateri brskalnik se naj koristi. Firefox je le ena od možnih opcij. V primeru da Selenium RC ne vsebuje privzete reference za vaš priljubljeni brskalnik^[9] lahko uporabite prefix “*custom” pri kateremu določite pot do vašega izbranega brskalnika. Metoda setBrowserUrl() nastavi URL iz katerega potekajo vsi testi.

Če vas zanima še kaj o test driven developmentu me kontaktirajte.

Happy blogging(coding)!

1. podrobno bom predtavil testiranje z Selenium RC v današnjem članku
2. če je sploh kaj testiranja pred produkcijo
3. ponavadi od stranke, katero pa opozorijo uporabniki
4. Sedaj vemo od kod ime Test-Driven Development
5. uporabnik, brskalnik
6. opcijsko – ni pogoj za izvajanje testov
7. predvidevajmo da imate PEAR že inštaliran
8. v njej prilagodite pot do podaljška
9. v kar dvomim ;)

Med pucanjem pošte sem naletel na link, ki me je pripeljal do slidov Rasmusa Lerdorfa. Prezentacija je iz avgustovske Drupal konference, ki je potekala pri naših sosedih.
Programerji smo baje čudna bitja. :) Odvisni smo od kompleksnosti in dostikrat ne znamo poiskati enostavno in očitno rešitev danega problema. To potem škodi performansi, skalabilnosti in varnosti aplikacij.^[1]

Avtor nam na primeru Laconice^[2] nazorno pokaže kako z enostavnimi, preprostimi prijemi izboljšamo performans aplikacije.



Internet Archive: Details: Drupalcon 2008 Szeged: Simple is hard

A must see vsakega developerja.

Happy blogging(coding)!

1. največ pa živcem nadrejenih
2. odprto kodna platforma za mikrobloging

Skoraj 10 let je od tega odkar sem napisal svojo prvo “aplikacijo” v PHP-ju. Skriptica je bila napisana v verziji 3^[1]. Brala je novice iz tekstovne datoteke in jih prikazovala na spletni strani, Amerika ;)
Prav toliko let je minilo da sem jo le dočakal … Koga pa?
Prvo slovensko PHP konferenco, ki se je pripetila 5 julija 2008 v prostorih Instituta Jožef Stefan v Ljubljani. Glavni krivec za njeno splavitev je Anže Žnidaršič, vodja tima razvijalcev na PRO PLUS d.o.o. (POP TV / Kanal A). Posebna zahvala gre še podjetju Domenci, partnerju in glavnemu pokrovitelju konference.
Glavni namen konference je bil vsekakor deliti znanje^[2] ter nabirati nova spoznanstva. To je bil vsekakor dober povod za udeležbo, čeprav ste mogoče že stari maček v znanju PHP-ja. Vedno je zanimivo slišati videnja ter način razmišljanja prekaljenih PHP razvojnikov.
Kljub temu, da sem bil z samo vsebino predavanj (Eclipse, Subversion, PHP frameworki, Template sistemi, Mootools, Unit in sistemsko testiranje kode, optimizacijo PHP kode …) že precej seznanjen^[3], sem pridno in pozorno poslušal predavatelje :)

Zatopljen v predavanja …

Predavanja

Še beseda, dve o samih predavanjih.
Konferenco je otvoril Anže in v nekaj stavkih obrazložil odkod sama ideja o PHP konferenci ter se obenem zahvalil vsem, ki so omogočili, da je do dogodka sploh prišlo. Slava jim!
Sledila je kratka predstavitev Institut Jožef Stefan, ter posebej še “Centra za prenos znanja na področju informacijskih tehnologij”.
Sebastjan Mislej nam je razkril enega izmed njihovih projektov/servisov z imenom VideoLectures. Vsa predavanja so se snemala in bodo kmalu na voljo za občo javnost. Sam center se med drugim ukvarja tudi z analizo podatkov. Počekirajte prototip iskalca z imenom SearchPoint.
Nato se je začelo zares …

Marko Štamcar, Najdi.si d.o.o

Tema Markovega predavanja je bila razvoj aplikacij v okolju Eclipse ter uporaba Subversna – sistema za nadzor različic^[4].
Eclipse kot IDE postane močan šele ko ga “našopamo” z plugini:

• za razvoj PHP-ja PHPEclipse
• dodatki za konteks menu AnyEdit Tools
• SQL klient – Eclipse SQL Explorer
• orodje za regular expression Regex Util
• klienta za Subversion^[5] Subversive in Subclipse

Prenesite si prosojnice od predavanja!

Gaj Capuder – spletnaPOSTAJA d.o.o.

Gaj je razglabljal o prednostih in slabostih uporabe Open Source Frameworkov. Če smo bolj natančni je v ožji izbor za primerjavo uvrstil 3 CMS-je in 3 PHP Frameworke. Ali upoprabiti OS produkte, je stvar posameznika. Dejstvo je, da če želimo razvijati aplikacije po RAD princupu, nam za lasten razvoj ostane bolj malo časa. Vprašajmo se zakaj bi izumljali toplo vodo vedno znova in znova?

Tit Petrič – Monotek d.o.o.

Tit se je spraševal kateri Template sistem je pravi. A je to nam vsem znani Smarty ali kateri od novejših (Heyes Template, Bob Template). Na koncu nam je predstavil Mini TPL, templating sistem lastnega razvoja, ki je bil prikazan prvič prav za čas PHP konference.
Med udeleženci se je porodilo vprašanje ali sploh obstaja potreba po učenju dodatnega template jezika kot je npr. Smarty saj današnji fleksibilni MVC frameworki (Zend Framework, CakePHP, Symfony …) počnejo točno to, kar smo počeli 5 let nazaj z Smarty-jem; ločevali aplikativni del kode od prikaza. Ali se nam “splača” v “View” komponento od frameworka vključiti template jezik?
Na spletu se odvijajo prave vojne okrog tega. Eno je povzročil sam pisec knjige o Smarty-ju Hasin Hayder. Jaz pa pravim kakor vam drago :)

Prenesite si prosojnice od predavanja!

Matej Balantič, PRO PLUS, d.o.o. (POP TV / Kanal A)

Matej je ljudstvu predstavil Mootools, kompakten in modularno objketno orentiran Javascript framework. Meni osebno sta bolj poznana YUI ter ExtJs^[6]. Je pa vedno dobrodošlo spoznati še kakšno “orodje”, saj nikoli ne veš kdaj ti bo prišlo prav :)

Vuk Ćosić

Vukovo predavanje sem skoraj v celoti zamudil^[7], saj sva z Vinijem po n-letih z malinovcem zalila najino ponovno snidenje :)

Jugoslav Petković – Domenca d.o.o.

Direktor podjetja Domenca nam je povedal svojo zgodbo o uspehu podjetja. Poleg tega se je Domenca kot partner in glavni pokrovitelj zelo izkazala: kosilo, pijača, kava, majice ter za grande finale ob samem koncu konference še podelitev MacBook-a.
Nekaj zanimivosti o samem podjetju:

• za razvoj aplikacij uporabljajo Zend Framework. Domenca je že četrto podjetje za katero vem, da so prešaltali na razvoj v tem Open Source frameworku. Ostala so Kabi, 3line ter Creatoor
• zaposleni imajo možnost neomejenega nakupa strokovne literature
• zaposleni se lahko zastonj izobražujejo po celemu svetu
• dodatni dan dopusta ob vstopu otroka v vrtec in osnovno šolo
• Domenca se bo kmalu predstavljala z novo identiteto in podobo
• vsi v Koornk^[8]

Anže Žnidaršič – PRO PLUS, d.o.o.

Vsi vemo, da ni kode brez hroščev, za testiranje pa si v večini primerov vzamemo premalo časa. Pojav hiperprodukcije pri slovenskih podjetjih ni nič novega, saj vsem primanjkuje programerjev. Še dobro se en projekt ne zaključi, že je tu nov. Anže nam je predstavil tehniko imenovano test driven development, pri kateri program testira program in to zna početi kar sam, brez naše pomoči.
Sam sem se z unit ter sistemskim testiranjem srečal v začetku leta 2007, ko sem si na domači disk pretočil Zend Framework 0.7^[9]. Po razpakiranju sem odkril mapo test kmalu zatem pa še maherja Sebastian Bergmann-a ter njegov PHPUnit. Več ali manj je vse ostalo pri raziskovanju …
Povzetek predavanja:

Testiranje naj bi bilo avtomatsko
Glavni problem ko spreminjamo kodo v aplikaciji, je ta, da jo s tem lahko pokvarimo. Spremembe so lahko nedolžne, pa vse do take, ko uporabnik naredi “totalno štalo” ko naleti na njo. Da pa ne bi vedno ročno ponavljali use case in teste, obstajajo zelo močne avtomatske rešitve – “unit testing frameworks”

Program naj testira program
Ideja je vedno enaka:

• napišemo drug program, da potestira našo aplikacijo
• program ne rabi iterakcije z uporabnikom da bi se zagnal
• v času izvajanja kreira log ali report kako so se testi obnesli
• program zaženemo takrat ko želimo testirat aplikacijo

Teste pišemo prej
Pisanje testov pred dejanskim pisanjem aplikacije zagotavlja hiter odziv po vsaki spremembi. Test driven development je metoda kako razvijati softver, ne samo metoda testiranja.

Tukaj sem navrgel več kot dve, tri besede ;) Gre za temo ki je zadnje leto, dve precej aktulna in ni open source projekta, ki ne bi razvoj testiral z Unit testi. Res vse pohvale Anžetu za tako dobro predstavitev.

Denis Arh, Domenca d.o.o.

Poleg Anžetovega, je bilo Denisovo predavanje eno izmed najbolj zanimivih.^[10] Vsi ki pišemo kodo želimo, da bi le ta tekla brez zapletov, da se izvaja čim hitreje, skratka da iz nje potegnemo maksimum. Predavatelj nam je razkril “male skrivnosti” velikih mojstrov :)
Ni samo pomemba optimizacija kode kot same, poskrbeti je potrebno tudi za brskalnike (minizacija script, content encoding …), web strežnik (optimizacija compilerja, uporaba reverse proxy-ja, zmanjševanje “file deskriptorjev” – o tem sem že sam pred kratkim modruval, …), ter podatkovni strežnik (r/w connection -> MASTER/SLAVE …) .
Opisal je še nekaj trikov in nasvetov kako testirati oz obremeniti web/podatkovni streznik in kako doseči čim krajši odzivni čas oziroma doseči čim večjo število requestov na sekundo.
Na koncu predavanja se je zastavilo zanimivo vprašanje in sicer ali je vertikalen scalability sploh potreben, glede na to, da je hardver poceni v primerjavi z delom programerja. Odgovor je sila preprost – common sense ;)

Miha Ceglar, Renderspace d.o.o.

Miha nam je pojasnil kako zagotoviti čim boljšo uporabniško izkušnjo. Predavanje od katerega sem odnesel najmanj, je pa tudi že utrujenost naredila svoje in je bila zbranost na dnu. Sama tema je bila prikazana mogoče malce preveč abstraktno in analitično. Najverjetneje smo programerji bitja, ki imamo radi bolj konkretne, otipljive stvari.

Epilog

Bravo, bravo in še enkrat bravo. Čestitke Anžetu, Domenci, Institutu Jožef Stefan, vsem predavateljem za odlična predavanja ter vsem PHP razvijalcem in entuziastom, ki smo prišli v tako velikem številu. Čestitke tudi Aleš-u srečnemu dobitniku MacBook-a, saj bo končno lahko razvijal na ta pravi mašini :)

ocena: sedi 5
minus: pogrešal uporabo DocBlock-a v PHP kodi oziroma psevdokodi pri podanih primerih
želje: še več podobnih dogodkov v prihodnje, interaktivne delavnice

Lahko samo rečem še PHP konferenca je uspela in Happy blogging(coding)!

1. 4 je bila še v zametkih
2. podobno kot se jaz trudim na blogu – za narodov blagor ;)
3. trenutno uporabljam, jo uporabljal v preteklosti ali vsaj testiral
4. po domače revision control system ;)
5. izbira je vaša
6. za desktop aplikacije
7. kriv sem priznam :)
8. več ne smem povedat
9. od takrat naprej ga budno spremljam
10. osebno meni

Pred nekaj dnevi sem želel preizkusiti nov Zend Studio For Eclipse 6.0.1. O samem PHP IDE-ju ne bi preveč razglabljal. Profesionalno orodje za bolj zahtevne uporabnike. Meni osebno je najbolj všeč Code Assist, integriran Debuging, Source Control z lokalno zgodovino, ter podpora za PHPUnit testing.
Beseda, dve o debugerju. Zend Studio omogoča lokalno in oddaljeno (na serverju) debugiranje. Za remote debugging rabite “Web Server Debugger”, kar je za Server-Client arhitekturo nekaj samoumevnega. Obstajata dva načina za to:

• inštalirate si Zend Platformo ali
• uporabite “Zend Debugger extension” za PHP

Inštalacija slednjega je elegantnejša in manj boleča za Apache in PHP :)

Inštalacija in konfiguracija Zend Debugerja

Izberite ustrezen debuger (Windows^[1], Mac OS X, Linux^[2]) ter verzijo PHP-ja (4.3.x, 4.4.x, 5.1.x ali 5.2.x) ter ga skopirajte v php direktorij kjer imate PHP podaljške^[3] :D
Dodajte naslednje vrstice v php.ini:

[Zend Debugger]
zend_extension=/usr/lib/php5/20060613/ZendDebugger.so #replace with your path
zend_debugger.allow_hosts=127.0.0.1
zend_debugger.expose_remotely=always

Skopirajte priloženo datoteko dummy.php v dokument root direktorij od Apache-ja. Ne pozabite reštartat web strežnik.
Če ste vse pravilno naredili vam bo to razkril phpinfo().
Da se vrnem nazaj na sam Zend Studio. ;)

!?*#?!

Po tem ko sem uspešno pretočil in razpakiral najnovejšo verzijo Zend Studia, zaženem installer. Po nekaj sekundah se le ta ustavi in izpiše da je prišlo do notranje napake v aplikaciji. Stack Trace navrže: java.lang.IllegalArgumentException: Malformed \uxxx encoding

Po tem ko je že kazalo, da ne bo iz mojega testiranja nič, sem le pogruntal, kaj ga tare…^[4] Če imamo v katerih od env spremenljivkah string ‘\u’, ki prikazuje trenutno prijavljenega uporabnika, ga bo installer zamešal za unicode znak in sam inštalacijski postopek se bo prekinil :D
Pri meni je šlo za PS1 spremenljivko, saj rad upurabljam ta. “fancy prompt”:

[...]
NM="\[\033[0;38m\]" #means no background and white lines
HI="\[\033[0;37m\]" #change this for letter colors
HII="\[\033[0;31m\]" #change this for letter colors
SI="\[\033[0;33m\]" #this is for the current directory
IN="\[\033[0m\]"

export PS1="$NM[ $HI\$(date +%H:%M:%S)$NM ]$IN$NM[ $HII\u@\h $SI\w$NM ]$ $IN"
[...]

Fancy prompt

Sedaj mi je samo ostalo, da zakomentiram PS1 spremenljivko v .profile datoteki in problem je bil odpravljen. Installer dela kot namazan:

Da še ne pozabim. Tale problem mi je uspelo reproducirati na Linux Ubuntu 8.0.4 platformi.

Happy blogging(coding)!

1. ZendDebugger.dll
2. ZendDebugger.so
3. extensions
4. Stric Google mi je malce pomagal

Po dolgem času spet nekaj za narodov blagor. Od zadnje objave je minilo kar nekaj časa. Delavniki so še vedno enaki: sestanki, ideje, realizacija, skratka ena velika “gužva” :)
Doma in v službi sem dokončno prešaltal na linux. Svojemu profilu na LinkedIn lahko počasi dodam napredno znanje in administracija Debian/Ubuntu based linux distribucij.
Še vedno veliko raziskujem in testiram. Med zadnjimi uspešnimi eksperimenti je inštalacija Leoparda (Mac Os X 10.5.2) na zunanjem USB disku na dve leti starem PC-ju z AMD Athlon 64 procesorjem. Kako mi je to uspelo, vam ne morem razkriti, saj je celotna stvar namenjena testiranju in ni ravno legalna ;) Koga zanima kaj več si naj ogleda OSx86 Project. Vsekakor je Mac Pro moj developer dream machine, saj mi kljub n-odprtim aplikacijam:

• Firefox z cca 50 odprtimi tabi
• Opera z cca 20 odprtimi tabi
• Safari z cca 10 odprtimi tabi
• Zend Studio for Eclipse
• Aptana Studio
• in še eno 20 raznoraznih programčkov

na PC-ju ni uspelo preobremenit procesor in s tem OS X, da bi ta vsaj malo počepnil. Kako celotna zadeva deluje na originalnem Macu pa si lahko le zamišljam.

Vlogger

Vlogger je majhen programček napisan v perlu s katerim zapisujemo Apache log datoteke razbite na mape virtual hostov. V posameznih mapah se nahajajo dostopi (access.log) po dnevih. Z malenkostnim popravkom skripte pa lahko v istih mapah shranjujemo tudi napake (error.log). Zadeva je zelo podobna cronolog-u, le da ne rabimo za vsak virtual host pisat svojo
direktivo, kar posledično zmanjša število dostop in s tem “file handlov”. Zakaj je to pomembo?
Recimo da ima vsak Virtual Host svoje log datoteke in nimamo nobene posebnosti pri zapisovanju logov (ne uporabljamo rotatorja/parserja ampak pustimo da Apache sam skrbi za log datoteke) bomo pri nekaj več sto Virtualnih Hostov kmalu naleteli na težave. Apache-ju bo kaj kmalu zmanjkalo tako imenovanih “file deskriptorjev“, ki jih ima na voljo.
Tukaj pridejo na pomoč razni “virtual web logfile rotater/parser” programčki. Med njimi je tudi vlogger. Sam sem stestiral vlogger na Debian/Ubuntu linuxu, Mac Os X ter FreeBSD-ju. Na vseh sistemih sem pred tem Apache2 že inštaliral in vlogger je na vseh deloval kot namazan.

Inštalacija

Linux:

sudo apt-get install vlogger

Mac Os X, FreeBSD:
Prenesi datoteko vlogger-1.3, odpakiraj in prekopiraj vlogger v /usr/sbin/ direktorij.

Konfiguracija

Vse kar moremo narediti, da bo vlogger špilal je da v globalno konfiguracijsko datoteko od Apache strežnika postavimo eno “CustomLog” direktivo in ta bo zapisoval dostopne loge za vsak Virtual Host in dan posebej.
Še prej pa popravimo “LogFormat” vrstico (tisto z imenom combined). Dodamo string %v na začetek le te. Odprimo apache konfiguracijsko datoteko^[1]:

[...]
#LogFormat "%h %V/%v %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
[...]

Popravimo še “CustomLog” vrstico

[...]
#CustomLog /var/log/apache2/access.log combined
CustomLog "| /usr/sbin/vlogger -t \"access.log.%Y-%m-%d\" -s access.log /var/log/apache2" combined
[...]

Tako bomo zapisovali vse log datoteke v poddirektorije^[2] v “/var/log/apache2″ z imenom access.log.yyyy-mm-dd z simbolicnim linkom “access.log”
Kot sem že omenil potrebujemo samo eno “CustomLog” direktivo za celotno konfiguracijo Apache-ja.

NE POZABITE izključit ostale “CustomLog” direktive, še posebej v Virtual Host konfiguracijah!

Dodatna prednost v eni sami dostopni datoteki, poleg že omenjenega limita “file deskriptorjev”, je seveda zmanjšanje server loada še posebej na straneh z veliko prometa.

Primer zapisa access logov na Ubuntu 6.06

ErrorLog mode

Z vlogger-jem lahko parsamo tudi napake. V tem modu je parsanje host-a izključeno in datoteka se zapiše z uporabo template datoteke v podani LOGDIR^[3].

[...]
#ErrorLog "/var/logs/apache2/error.log"
ErrorLog  "| /usr/sbin/vlogger -e -t \"error.log.%Y-%m-%d\" -s error.log /var/log/apache2/errors"
[...]

Prav tako nastavimo level napak, ki se naj shranjujejo v ErrorLog. Za produkcijo je priporočljiv vsaj level Critital Conditions.

[...]
#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel crit
[...]

Če želimo v error log ujeti še PHP napake v php.ini-ju nastavimo naslednje:

[...]
;Log errors into a log file (server-specific log, stderr, or error_log (below))
; As stated above, you're strongly advised to use error logging in place of
; error displaying on production web sites.
log_errors = On
[...]

Primer zapisa error loga na Ubuntu 6.06

Tip

Z malim popravkom vlogger skripte lahko error.log datoteke zapisujete v Virtual Host mape, kjer se že nahajajo access.log datoteke. Ne priporočam tega v produkciji, saj lahko spet naletimo na problem limita “file deskriptorjev”
Gre bolj za pomoč programerjem, saj opažam da nemalokateri razvijalec kliče na pomoč ob prvi napaki.
Odprimo vlogger skripto in spremenimo^[4]:

#!/usr/bin/perl - T v
#!/usr/bin/perl
[...]
        mkdir("$ARGV[0]");
        #print STDERR
        #  "[vlogger] target directory $ARGV[0] does not exist - exiting.\n\n";
        #exit;
[...]

S tem najprej disablom da bi perl preverjal tako imenovane “tainting checks”, ter kreiramo mapo za error.log če ta ne obstaja. Ker se target direktorij za error log preverja takoj ob zagonu Apache-ja, bi se v nasprotnem primeru skripta ustavila in bi se zapisoval samo access.log.

Sedaj samo še dodamo direktivo v Virtual Host konfiguracijo

[...]
<VirtualHost *>
    DocumentRoot "/opt/local/apache2/htdocs/virtualhost"
    ServerName virtualhost
    ErrorLog  "| /usr/sbin/vlogger -e -t \"error.log.%Y-%m-%d\" -s error.log /var/log/apache2/virtualhost"
</VirtualHost>
[...]

Access in Error Log v isti mapi od Virtual Hosta.


Happy blogging(coding)!

1. linux: /etc/apache2/apache2.conf; mac os x: /opt/local/apache2/conf/httpd.conf; freeBSD: /usr/local/etc/apache22/httpd.conf
2. virtualhost.com, virtualhost1.com, …
3. npr: kreiramo mapo /errors v /var/log/apache2
4. v vrsticah 1 in 174

Dol potegnite novi SQL Server 2005 Driver za PHP.

1. čisto
2. tudi Express Edition