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 ;)

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

Perl module z imenom SQLFairy (SQL::Translator) sem odkril čisto po naključju med tem ko sem se spoznaval z Doctrine. Ta ORM za PHP do verzije 0.11 ne omogoča da bi mu preprečili avtomatsko “singularizacijo” “podatkovnih modelov” ki jih generiramo iz trenutne baze. Da ponazorim: če imamo tabelo z imenom “files”, bo Doctrine generiral model z imenom “File” in ne “Files”. Čeprav mi ni ravno jasno kako^[1], določeni modeli dobijo kar čudna imena ;)^[2] .
Da ne bi vedno znova popravljal YAML datoteko, ki opisuje shemo podatkovne baze, sem se lotil malega raziskovanja. Naletel sem na …

SQLFairy …

ali z drugim imenom SQL::Translator. To orodje za SQL, je trenutno najbolj enostavni način za manipulacijo z “podatkovnimi strukturami”^[3] na vse mogoče načine. Služi nam lahko za konvertiranje med različnimi “dialekti” CREATE sintaks (npr: iz MySQL v PostgreSQL), za virtualizacijo shem (pseudo-ER diagrami z uporabo: GraphViz ali GD-ja), za konvertiranje ne-RDMBS datotek v SQL sheme (Excelove preglednice), ter še kaj bi se našlo.
Z razbitjem kode v “parserje”^[4] in “izdelovalce”^[5], je zmožen kombinacije kateregakoli parserja z izbranim izdelovalcem. Trenutno pa je SQLFairy sposoben uporabljati le definicijski del SQL-a^[6], ne pa same manipulacije s podatki^[7].

Namestitev in konfiguracija

Za začetek si prenesite SQL::Translator na disk. Ker gre za standardne Perl module, je inštalacija sila preprosta, sledite le navodilam v README fajlu.^[8]
Po razpakiranju paketa sledimo navodilom:

$ perl Build.PL
$ ./Build
$ ./Build test
$ su
# ./Build install

V primeru da nimate inštaliranih vseh ustreznih modulov, ki jih rabi SQL::Translator se bo skripta Build.PL ustavila. Če do sedaj niste kaj prida uporabljali Perl bo vam najverjetneje manjkal modul z imenom’Module::Build‘, ki je potreben za grajenje in inštalacijo Perl modulov. Najenostavnejši način, da si inštaliramo manjkajoče zadeve, je z uporabo CPAN-a. Ukaze lahko vnašamo direktno v konzolo ali pa preko -MCPAN vmesnika.^[9]
Primer vnosa direktno v konzolo:

# sudo perl -MCPAN -e 'install Module::Build'

Sledila bo konfiguracija CPAN modula, ter inštalacija Module::Build. Konfiguracija se ustavi, če nimate vseh ustreznih programčkov, ki jih CPAN rabi. Meni sta manjkala: NcFtp klient ter GnuPG. Po cca. 15 minutah v pričakovanju vtipkamo nesrečni “./Build install” :)

Sqlt

Če ste se uspešno prebili do te točke bi sedaj morali imeti na voljo ukaz “sqlt”. Ukaz konvertira SQL sheme z uporabo SQL::Translator-ja. Tipičen primer uporabe je:

sqlt -f MySQL -t PostgreSQL  dump_mysql.sql > dump_postgresql.sql

Končni rezultat je opis tabel v datoteki dump_postgresql.sql v sintaksi PostgreSQL-a, ki smo ga konvertirali iz MySQL sintakse.
Spisek vseh možnih parserjev in izdelovalcev dobimo:

sqlt -l

Spisek vseh možnih parserjev in izdelovalcev.

Use cases

Kot primer bomo vzeli SQL DDL psevdokodo, ki jo bomo iz MySQL sintakse konvertirali v različne formate.
Psevdokoda:

CREATE TABLE bugs (
  bug_id            INTEGER NOT NULL PRIMARY KEY,
  bug_description   VARCHAR(100),
  bug_status        VARCHAR(20),
  reported_by       VARCHAR(100),
  assigned_to       VARCHAR(100),
  verified_by       VARCHAR(100)
);

MySQL sintaksa:

CREATE TABLE `bugs` (
  `bug_id` int(11) NOT NULL,
  `bug_description` varchar(100) default NULL,
  `bug_status` varchar(20) default NULL,
  `reported_by` varchar(100) default NULL,
  `assigned_to` varchar(100) default NULL,
  `verified_by` varchar(100) default NULL,
  PRIMARY KEY  (`bug_id`)
) ENGINE=MyISAM;

Konverzija v PostgreSQL:

sqlt -f MySQL -t PostgreSQL bugs_mysql.sql > bugs_postgresql.sql

PostgreSQL sintaksa:

CREATE TABLE "bugs" (
  "bug_id" bigint NOT NULL,
  "bug_description" character varying(100) DEFAULT NULL,
  "bug_status" character varying(20) DEFAULT NULL,
  "reported_by" character varying(100) DEFAULT NULL,
  "assigned_to" character varying(100) DEFAULT NULL,
  "verified_by" character varying(100) DEFAULT NULL,
  PRIMARY KEY ("bug_id")
);

Konverzija v YAML:

sqlt -f MySQL -t YAML bugs_mysql.sql > bugs.yaml

YAML sintaksa:

schema:
  procedures: {}
  tables:
    bugs:
      constraints:
        - deferrable: 1
          expression: ''
          fields:
            - bug_id
          match_type: ''
          name: ''
          on_delete: ''
          on_update: ''
          options: []
          reference_fields: []
          reference_table: ''
          type: PRIMARY KEY
      fields:
        assigned_to:
          data_type: varchar
          default_value: NULL
          extra: {}
          is_nullable: 1
          is_primary_key: 0
          is_unique: 0
          name: assigned_to
          order: 5
          size:
            - 100
        bug_description:
          data_type: varchar
          default_value: NULL
          extra: {}
          is_nullable: 1
          is_primary_key: 0
          is_unique: 0
          name: bug_description
          order: 2
          size:
            - 100
        bug_id:
          data_type: int
          default_value: ~
          extra: {}
          is_nullable: 0
          is_primary_key: 1
          is_unique: 0
          name: bug_id
          order: 1
          size:
            - 11
        bug_status:
          data_type: varchar
          default_value: NULL
          extra: {}
          is_nullable: 1
          is_primary_key: 0
          is_unique: 0
          name: bug_status
          order: 3
          size:
            - 20
        reported_by:
          data_type: varchar
          default_value: NULL
          extra: {}
          is_nullable: 1
          is_primary_key: 0
          is_unique: 0
          name: reported_by
          order: 4
          size:
            - 100
        verified_by:
          data_type: varchar
          default_value: NULL
          extra: {}
          is_nullable: 1
          is_primary_key: 0
          is_unique: 0
          name: verified_by
          order: 6
          size:
            - 100
      indices: []
      name: bugs
      options:
        - ENGINE: MyISAM
      order: 1
  triggers: {}
  views: {}
translator:
  add_drop_table: 0
  filename: bugs_mysql.sql
  no_comments: 0
  parser_args:
    db_password: ~
    db_user: ~
    dsn: ~
    field_separator: ~
    mysql_parser_version: ~
    record_separator: ~
    scan_fields: 1
    trim_fields: 1
  parser_type: SQL::Translator::Parser::MySQL
  producer_args:
    add_prefix: ~
    add_truncate: ~
    db_password: ~
    db_user: ~
    dsn: ~
    imap_file: ~
    imap_url: ~
    indent: ~
    newlines: ~
    package_name: ~
    prefix: ~
    pretty: ~
    skip: ~
    skiplike: ~
    title: ~
    tt_conf: {}
    tt_vars: {}
    ttfile: ~
  producer_type: SQL::Translator::Producer::YAML
  show_warnings: 0
  trace: 0
  version: 0.09000

Konverzija v XML:

sqlt -f MySQL -t XML bugs_mysql.sql > bugs.xml

XML sintaksa:

<?xml version="1.0" encoding="UTF-8"?>
<!--
Created by SQL::Translator::Producer::XML::SQLFairy
Created on Wed Jun 25 13:40:31 2008
 -->
<schema name="" database="" xmlns="http://sqlfairy.sourceforge.net/sqlfairy.xml">
  <extra />
  <tables>
    <table name="bugs" order="1">
      <extra />
      <fields>
        <field name="bug_id" data_type="int" size="11" is_nullable="0" is_auto_increment="0" is_primary_key="1" is_foreign_key="0" order="1">
          <extra />
          <comments></comments>
        </field>
        <field name="bug_description" data_type="varchar" size="100" is_nullable="1" default_value="NULL" is_auto_increment="0" is_primary_key="0" is_foreign_key="0" order="2">
          <extra />
          <comments></comments>
        </field>
        <field name="bug_status" data_type="varchar" size="20" is_nullable="1" default_value="NULL" is_auto_increment="0" is_primary_key="0" is_foreign_key="0" order="3">
          <extra />
          <comments></comments>
        </field>
        <field name="reported_by" data_type="varchar" size="100" is_nullable="1" default_value="NULL" is_auto_increment="0" is_primary_key="0" is_foreign_key="0" order="4">
          <extra />
          <comments></comments>
        </field>
        <field name="assigned_to" data_type="varchar" size="100" is_nullable="1" default_value="NULL" is_auto_increment="0" is_primary_key="0" is_foreign_key="0" order="5">
          <extra />
          <comments></comments>
        </field>
        <field name="verified_by" data_type="varchar" size="100" is_nullable="1" default_value="NULL" is_auto_increment="0" is_primary_key="0" is_foreign_key="0" order="6">
          <extra />
          <comments></comments>
        </field>
      </fields>
      <indices></indices>
      <constraints>
        <constraint name="" type="PRIMARY KEY" fields="bug_id" reference_table="" reference_fields="" on_delete="" on_update="" match_type="" expression="" options="" deferrable="1">
          <extra />
        </constraint>
      </constraints>
      <comments></comments>
    </table>
  </tables>
  <views></views>
  <triggers></triggers>
  <procedures></procedures>
</schema>

Happy blogging(coding)!

1. Nisem se poglabljal v kodo ki generira imena modelov
2. moneta je postala “Monetum”
3. structured data definitions – schemes
4. parsers
5. producers
6. CREATE, ALTER
7. INSERT, UPDATE, DELETE
8. Tukaj predvidevamo da imate Perl ustrezno inštaliran na vašem računalniku
9. kot super-user

• ekipa sodelujočih pri razvoju iz vrst Zend-a, IBM-a, OmniTI, …
• kvaliteta in testiranje – čez 4.000 unit testov. Vse knjižice so testirane z uporabo PHPUnit.

MVC – Model View Controller
Velika večina “frameworkov” se vedno znova vrti okrog lastne implementacije MVC-ja. Če želite uiti iz tega začaranega kroga, je boljše, da tak framework me uporabite. Seveda tudi Zend Framework vključuje module, ki vam pomagajo pri postavitvi MVC-ja in načinov kako to dosežemo je kar nekaj. Z malce programerskega znanja boste lahko vključili že obstoječe “third-party” knjižice kot so SwiftMailer, Smarty, Propel, ADOdb, … ali pa svoje knjižice zamenjali z Zendovimi:

• za delo z sejami – Zend_Session
• za keširanje podatkov, objektov, spletnih strani – Zend_Cache
• …

A je za začetnike?
Možno, je da si bom s to izjavo nakopal kakšnega “sovražnika”, ampak Zend Framewok je profesionalen izdelek in ni ravno namenjen začetnikom, ki se šele spoznavajo s PHP-jem. Čeprav je glavna filozofija in moto frameworka “Extreme simplicity”, so določeni pogledi MVC-ja in ostalih modulov precej bolj kompleksni od ostalih frameworkov (CodeIgniter, CakePHP, …). Če niste ravno naklonjeni, da občasno več ur namenite brskanju po izvorni kodi ali pa vam je uporaba API-ja tuja, vam svetujem da si omislite kaj drugega!

Primer uporabe Zend Framework knjižic
Ostane nam še demo primer uporabe. Test case je vzet iz vsakdanjika. Preko URL-ja preberemo parameter id, če id ni nastavljen ali pa ni tipa int ga nastavimo na nulo. Če slučajno zaznamo metodo POST ustavimo skripto.

Stari način:

if (isset($_GET['id']) and $_GET['id'] != "") {
	$id = (int) $_GET['id'];
} else {
	$id = 0;
}

if (strtolower($_SERVER['REQUEST_METHOD']) == 'post')
	die('POST detected');

Zend Framework:

/** Zend/Validate.php */
require_once 'Zend/Validate.php';

/** Zend/Controller/Request/Http.php */
require_once 'Zend/Controller/Request/Http.php';

/** request object */
$request = new Zend_Controller_Request_Http();

/** id */
$id = ( Zend_Validate::is($request->getQuery('id'), 'Int') ) ? (int) $request->getQuery('id') : 0;

if ($request->isPost())
	die('POST detected');

Kakor vam drago :)

Happy blogging(coding)!

1. Library
2. overriding, subclassing

“404 Not Found” v naslovu če gre za Apache.

“Page cannot be found” v pimeru IIS-ja.

Čeprav ni nobenega security riska^[2], je vse skupaj grdo, ter uporabniku neprijazno.
Z veliko žalostjo opažam, da večina razvijalcev in webmasterjev še vedno “prezira” 404 napako. Kmica^[3] mi je pa padla na oči, ob ugotovitvi, da so tudi podjetja, ki se ukvarjajo z izdelavo spletnih strani enako ignorantska.

• http://www.mojsplet.net/404
• http://www.modronebo.net/404
• http://www.red-orbit.com/404
• http://www.portal.si/404
• http://www.ewrs.net/404
• http://www.g-server.com/404

Osebno kot razvijalcu in skrbniku spletnih strani, se mi zdi pomembno, da dobim obvestilo^[4], ko pride do napake v spletni aplikaciji, da lahko na njo ustrezno reagiram.

Napaka 500
ali interna napaka na strežniku je standardna napaka spletnega protokola HTTP, ki pove da je šlo nekaj narobe na strežniku na katerem se nahaja spletna stran, ampak strežnik ne ve natančno za kakšen problem gre. Napaka je tipa “server-side”, kar pomeni, da ni nič narobe z našim računalnikom ali internetno povezavo, temveč je kriv spletni strežnik. Web strežnik bi moral generirati interni error log v katerem se nahaja podroben opis napake. Za skrbnika spletne strani je toliko bolj pomembno da na tako napako čimprej reagira. Sistem dodatnega obveščanja po elektronski pošti postane nujno zlo.

Moč “Error Handlerja”

Na večini spletnih strežnikov je možno te napake prirediti tako, da prikažejo stran, ki je v večjo pomoč kot privzete. V popularnem spletnem strežniku Apache to storimo na preprosti način tako, da postavimo datoteko .htaccess na spletni strežnik.

ErrorDocument 404 /404.php
ErrorDocument 500 /500.php

Moj “Error Handler” ni tako prepost, saj je vkomponiran v web aplikacijo in lovi naslednje errorje^[5]:

404 Error – Not Found

500 Error – Internal Server Error : “pohendla” tudi vse Exceptione, ki jih “vrže” spletna aplikacija

403 Error – Forbidden : v aplikacijo je vkomponiran Acl, ki skrbi za avtorizacijo uporabnikov. V primeru, da uporabnik hoče dostopat do neavtoriziranega dela, aplikacija vrže 403 napako.

V bližnji prihodnosti bom obelodanil še “code snippet” za preprost error handler za PHP na Apache-ju^[6].

Happy blogging(coding)!

1. v bistvu handlam tri
2. Pri Apacheju se ponavadi izpiše tudi verzija. Če ta ni vsaj verzija 1.3.37, je strežnik lahko kar hitro tarča hekerskega napada.
3. prekmursko: tema
4. mail, RSS, …
5. z malce sarkazma, obenem pa pošlje še obvestilo o napaki po elektronski pošti
6. če bo želja tudi za ASP na IIS-u

Blog! O čem?
Predvsem seveda “reklamiranju moje dejavnosti”. Vsi prispevki na blogu pa bodo imeli skupno nit oziroma slogan – Human knowledge belongs to the world. :) Našli boste kakšen pameten tanač^[1], “code snippet”, tutorial, … Če drugega ne se boste lahko kratkočasili nad mojim modrüvanjon^[2]. Zapisi na blogu so zanimi in privlačni predvsem za “web developerje”, ki si svoje znanje in izkušnje šele nabirajo. Ne bom se trudil pisati v popolni slovnično pravilni slovenščini, vmes bo padla kakšna angleška skovanka, za posladek še prekmurska rejč^[3].


Prvi post
Kot je glava polna idej, bo ta prvi prispevek ena velika mešanica – en mindenfele^[4] izlivov in razmišljanj. Dobra dva meseca nazaj sem zaključil z delom v AV studiu in se odločil za meni ugodnejšo opcijo – delo doma. Kar naenkrat se je pojavila potreba po predstavitveni spletni strani. Klasične spletne strani so “pase”, torej je bila edina pametna izbira blog. Odločil sem se, da bom “hvatal krivine”, in uporabil “open source”, saj mi že časa za redne projekte skorajda primanjkuje. Vprašanje izbire je bila trivialna odločitev, saj sem bil iz vseh strani bombardiran s slavospevi Wordpressu in malem morju več ali manj (ne)uporabnih pluginov.
Nemudoma sem to “čudo tehnike” potegnil dol z neta. Programerska žilica mi ni dala miru in pogledal sem v php “source fajle”. Sledilo je veliko razočaranje! Kje je PHP 5 in tri leta razvoja? Trezna glava je počasi prevladala poklicno deformacijo in odgovor je bil na dlani. Na več kot 77% vseh strežnikov, ki imajo inštaliran PHP še vedno kraljuje verzija 4, kar pomeni za WP velik delež pogače. Dejstvo je, da je v PHP 4 lažje programirat^[5], kar prinaša kvantiteto pluginov ki jih pišejo uporabniki stari od 10 do 90 let. Wordpress – zagotovljena zgodba o uspehu.
PHP 5 je hiter in stabilen, v razvoju je že verzija 6, in ni prav nič pretresljivega, da se je PHP odločil da bo “pokopal” verzijo 4. Poskrbeli bodo samo za kritične “security” flajštre^[6]. A to dejansko pomeni konec verzije 4? A bodo sedaj vsi naenkrat na vrat na nos presedlali na 5-tko? Dvomim! Poglejmo na primer samo stari dobri ASP. Zadnja verzija 3.0 je ugledala luč sveta novembra 2000, od takrat naprej ni bilo sprememb. Microsoft ne nudi več tehnične podpore, ampak pod taktirko IIS7 še vedno lepo laufa. Precej programerjev danes razvija web aplikacije v klasičnem ASP-ju. Zakaj ne gredo enostavno na ASP.NET ki je naslednik starine? Odgovor leži v arhitekturi frameworka. ASP.NET je tako imenovani “event-driven” framework in programerja vzpodbuja da razvija aplikacije po “event-driven” GUI vzorcu z razliko od ASP in PHP, ki sta klasična “web-skriptna” jezika. Za prehod na novejšo različico je potrebno drugačno razmišljanje.

Podoben vzorec lahko najdemo v PHP-ju. Proceduralno programiranje v 4-ki zahteva drugačne pristope kot pa objektno programiranje 5-ke z vsemi njenimi čari^[7]. Ta miselni preskok je za marsikaterega programerja pretrd oreh in se rajši držijo “starih” (ra)(na)z(v)ad.
PHP 5 se prepočasi prebija na strežnike^[8]. A to pomeni smrt 6-ki še preden se je rodila? :)
Upajmo da ne, he, he. V izogib tega so se združili posamezniki iz nekaterih glavnih “open source” projektov in nastal je GoPHP 5. Projekt so med drugim podprli: Drupal, Gallery, PEAR, PHPUnit, PHPMyAdmin, … in kopica ponudnikov “web hostinga“. Preden so nekateri pristopili k projektu, so se na netu prirejale prave borbe in verbalna klanja okrog PHP verzij in katera je “Über Alles”. Več ali manj se je vse odvijalo po načelu “svaki cigo svoga konja hvali”. Seveda diskusija ni prizanesla niti WordPressu oziroma njenemu “očetu” Mattu Mullenwegu, ki na svojem blogu piše: Fast forward 3 more years and PHP 5 has been, from an adoption point of view, a complete flop.
He, he, pravi komedijant tale Matt, ni kaj. :) No, kakorkoli že se bo Matt odločil, Wordpress nima problemov z PHP 5, le njegovih potencialov ne izkorišča, kar je prav škoda.
Nazaj k blogu. Naslednji korak je bil oblačenje in okinčanje^[9]. Web design mi nikoli ni šel preveč od roke, na srečo pa je na netu cela armada “Wordpress Themes“. Iskal sem nekaj prepostega in bog ne daj kockastega. :) Navdušil me je iTheme, čeprav domači računalnik poganja Linux. Z malce “šaranja” po kodi sem dodal še en stolpec in spremenil glavo dokumenta. Kot web developer uporabljam trenutne standarde in včasih že malce pretiravam. Čeprav večina templatov zagotavlja, da so XHTML Valid mi je rdeč križec HTML Validatorja govoril ravno obratno. Pridem do spoznanja, da po kodi rovari Wordpressov WYSIWYG editor in ker že skoraj desetletje kucam HTML na roke, je izklop le tega edina prava rešitev. Kljub temu Wordpress še naprej avtomatično formatira poste in ne zaključuje pravilno paragraph tagov? Ko že obupam in se spravim popravljat kodo, se vseeno spomnim na strica Googla, ki najde plugin z imenom Disable wpautop. Vsebuje le dve vrstici:

remove_filter ('the_content',  'wpautop');
remove_filter ('comment_text', 'wpautop');

Ti odstranita “buggy” funkcijo wpatuop iz “hooka” in s tem preprečita avtomatsko formatiranje teksta. Tisti, ki malce bolje poznate Wordpress veste da filtri – “Filters” in akcije – “Actions” skupaj tvorijo tako imenovane “Hooks”, ki enostavno omogočijo pluginu da se priklopi v WordPress.
Res, vse zveni tako enostavno. Kot primer podajam najbolj preprosti Foo Bar plugin, ki na koncu posta doda tekst:

/** add foo bar filter on content */
add_filter('the_content', 'addfooBar');

/**
 * Add foo bar at end of the content
 *
 * @param string $content
 * @return string
 */
function addFooBar($content) {
	$foo = 'Foo Bar';

	return  $content . " $foo";
}

Za komentarje v kodi uporabljam Documentation block oziroma DocBlock ampak o tem kdaj drugič. ;) Vrnimo se k pluginih. Niso vsi tako nedolžni kot izgledajo, zato previdnost pri njihovi uporabi ni odveč. Do pred kratkim je bil Ultimate Tag Warrior ranljiv na SQL injection. Kaj to za čuda je v kakem prihodnjem postu, je pa ta vrsta varnostne luknje zelo pogosta pri programerjih, saj enostavno pozabijo, da je potrebno vsak uporabniški vnos preverjati in filtrirati. Na varnostno luknjo sem opozoril tudi avtorico plugina, ki je sicer že popravila napako. Še screen: SQL injection UTW – PoC. No Matt, če bi bil Wordpress napisan za PHP 5 bi naprimer lahko uporabil PDO exstension, ter parameteriziran SQL vnos in bi zadeva bila s tem zaključena ;)
Hrošči v aplikacijah so čisto nekaj običajnega, to bo potrdil vsak, ki je napisal vsaj eno vrstico kode. Ni aplikacije, ki bi bila stoodstotno brez napak. Da bi programer imel čimmanj poznejšega “debuggiranja”^[10] mora dobro poznati okolje v katerem programira. Poznavanje robnih pogojev določenega problema, vsako preverjanje in filtriranje vnosnih podatkov, ustrezno reagiranje na napake, lahko že prepreči nepričakovano obnašanje programa oziroma aplikacije, ki se v najbolj nežni obliki pokaže kot “sesuvanje”, da pa o črnih scenarijih nite ne bomo razmišljali. Tudi sam Wordpress ni nobena izjema kar se tiče “luknjavosti”, o tem se lahko prepričate na spletni strani od NVD-ja (National Vulnerability Database).

Epilog
Treba bo zaključiti, ker bom drugače pisal še tri dni ;) Upam, da vam s tem prispevkom nisem odvrnil želje od bloganja in uporabe Wordpress-a. ;) Če imate željo po “izlivih” v elektronski obliki je Wordpress pravo orodje za to^[11], saj ga obdaja ogromen “cummunity”, ki skrbi da nikoli ne zmanjka oblekic in priboljškov za njega. Poskrbite za to, da boste imeli na strežniku inštalirano karseda “friško”^[12] verzijo. Po vsaki posodobitvi preverite vaše plugine, obstaja velika verjetnost da ne bodo več delovali. :) Za sledenje verzij pluginov, ki jih imate nameščene na vašem blogu priporočam WP Plugins Tracker. Ne uporabljajte tiste, katerega zadnja posodobitev je bila pred več kot pol leta, definitifno obstaja boljša ekvivalenca. In nabolj važno: redno skrbite za backup!

Happy blogging(coding)!

1. nasvet; Dala mi je že ene par dobrih tanačof.
2. gostobesedno in nesmiselno govoriti; Ne modrüj telko.
3. beseda; Tak se guči, tao je rejč!
4. mindenfele: raznorazne
5. če izvzamemo da ne programiramo objektno v PHP 5 – a ima potem sploh smisel preiti na petko :)
6. flajšter: obliž
7. konstruktor, dedovanje, polimorfizem, statične metode, php design paterni …
8. le dobrih 20% ga je na vseh svetovnih inštalacijah
9. okrasiti; Krispan so inda okinčali z oreji pa s süjon sadjon.
10. razhroščevanja – postopek iskanja in odpravljanja softverskih hroščev
11. pustimo programsko kodo v ozadju, he, he
12. sveže: Pobrao san friško šalato.