Dependency Injection czyli wstrzykiwanie zależności to ostatnio bardzo modna technika tworzenia elastycznego kodu. Niektórzy marudzą, że jest to tylko chwytliwa nazwa dla prostej metody poprawiającej jakość kodu. Jakby nie było wstrzykiwanie jest warte dogłębnego poznania.

Ostatnio pisze dużo kodu pobierającego dane z bazy. Osoby piszące metody wykonujące kod SQL mają dwa podejścia. Pierwszym jest tworzenie dużej liczby parametrów.

public function get_products_by_category($category_id, $order_by, $order_desc, $limit, $offset);

Proste, jednak trzeba wpisywać za każdym razem wszystkie parametry. Oczywiście można to zapisać w postaci domyślnych wartości:

public function get_products_by_category($category_id, $order_by ='price', $order_desc='DESC', $limit=10, $offset=0);

Niestety jeżeli chcemy pobrać kolejnych 10 produktów musimy podać wszystkie parametry, pomimo że poprzednie pozostają domyślne. Rozwiązaniem jest drugie podejście czyli upakowanie wszystkich dodatkowych parametrów w jeden.

public function get_products_by_category($category_id, $options=null);

Ustawiłem zmienną $options domyślnie na null ponieważ nie zawsze chcemy coś zmieniać, czasami defaultowe zapytanie nam wystarcza. Do działania potrzebujemy wewnątrz kilka dodatkowych linii kodu. oto przykład z wersją zmiennej $options jako tablica:

public function get_products_by_category($category_id, $options=array())
{
  if(array_key_exists('limit', $options))
    $limit = $options['limit'];
  else
    $limit = 10;

  // [...]

  $this->db
    ->from('products')
    ->where('category_id', $category_id)
    ->orderby($orderby, $direction)
    ->limit($limit, $offset);
  return $this->db->get();
}

Niestety przy wielu takich metodach duplikuje się kod :( Tutaj przychodzi z pomocą Dependency Injection. Oto metoda która ustala limity dla zapytania a pobiera 2 parametry refernecje do obiektu Database oraz tablice opcji do ustawienia.

public function get_products_by_category($category_id, $options=array())
{
  $this->set_limit($this->db, $options);

  $this->db
    ->from('products')
    ->where('category_id', $category_id);

  return $this->db->get();
}

protected function set_limit($db, $options)
{
    if(array_key_exists('limit', $options))
        $limit = $options['limit'];
    else
        $limit = $this->default_limit;

    if(array_key_exists('offset', $options))
        $offset = $options['offset'];
    else
        $offset = $this->default_offset;

    $db->limit($limit, $offset);
}

Przy większej liczbie metod do ustalania parametrów można na końcu każdej z nich dodać return $db aby umożliwić tzw. chaining dla metod. Jak pisałem DI nie jest niczym odkrywczym. Nazwanie tej techniki chwytliwą nazwą Dependency Injection powoduje że programiści o niej dłużej pamiętają, tworzać tym samym lepszy kod.

P.S. to jest wstęp do DI. Temat jest naprawdę szeroki, warto się nim zainteresować. Daje duże możliwości dzięki takim mechanizmom (już trochę bardziej zaawansowanymi) jak DI Container.

Właśnie skończyłem czytać książkę “Jeszcze wydajniejsze witryny internetowe Przyspieszanie działania serwisów WWW” autorstwa Steve Souders i mam mieszane uczucia. Książka traktuje raczej o detalach pewnych technikach optymalizacji witryn internetowych w specyficznych przypadkach niż o optymalizacji jako całościowa strategia budowania aplikacji www.

Książka w głównej mierze dotyczy pisania wydajnego kodu Java Script oraz umieszczania go w odpowiedni sposób aby nie spowalniał ładowania się witryny. Zamiast pokazać najczęściej wykorzystywaną technikę ładowania bibliotek JS pokazane są wszelkie możliwe rozwiązania. Co gorsze wszystkie te rozwiązania są analizowane dogłębnie pokazując ich “zalety” powodując że czytelnik pod koniec do końca nie jest pewny które techniki są dobre a które gorsze :(

Autor ma ogromną wiedzę na temat optymalizacji kodu Java Script i sam tylko rozdział “Pisanie wydajnego kodu JavaScript” jest wart kupienia książki. Znajdziecie tu nie tylko ogólne triki jak przyszpieszyć kod java script ale także przykłady jakie funkcje JS są wydajniejsze w jakich przeglądarkach. Szczególnie warto poczytać o case’ach dotyczących przeglądarek IE.

Moją ulubioną częścią ksiązki są rozdziały na temat grafiki – wreszcie jakieś kompletne źródło wiedzy jak optmalizowac grafikę dla internetu – oraz optymalizacji stylów CSS. Miałem kilkuminutowy wielki LOL jak przeczytałem że przeglądarki interpretują selektory CSS nie od lewej do prawej tylko od prawej do lewej. Tak więc selektor #lista > li jest wolniejszym selektorem niż .li-listy. W książce autor proponuje aby twórcy kodu CSS nie uzywali selektorów dla tagów, dzieci czy potomków, a zamiast tego tworzy specjalne idiki i klasy.

Na końcu jest dostępna lista ciekawych programów pomocnych przy optymalizacji stron www. Książka bardzo dobra jednak jest kierowana do osób które mają już doświadczenie w temacie. Dla noobów zdecydowanie odradzam.

Narzeka się na młodzież, że się nie uczy i w ogóle jest bee. Co jednak nauczyciele robią by zaszczepić bakcyla do szeroko pojętej nauki? Nic!!! Dzieci uczy się bezmyślnego używania wzorów zamiast pokazać piękno natury i jej praw.

Można inaczej? Oczywiście, że można :) Oto 2 przykłady jak poważną wiedzę można przekazać w dość przyjaznej formie dla młodego pokolenia:

Więcej na http://www.symphonyofscience.com/

W ostatnim projekcie grafik wymyślił sobie główną nawigację za pomocą “buttonów” z zaokrąglonymi rogami oraz dodatkowym efektem w postaci cienia dla buttona. Ponieważ grafik jest jednocześnie klientem postanowiłem nie iść na zbyt duży kompromis i nie pisać dziwnego kodu i postarać się stworzyć w miarę semantyczny kod HTML.

Idea jest prosta, menu jest pewnego rodzaju nieuporządkowaną listą ul w której elementy li posiadają element linku a. Kod powinien wyglądać następująco:

<nav>
  <ul>
    <li><a href=#>Anchor Text</a></li>
    <li><a href=#>Anchor Text</a></li>
  </ul>
</nav>

W pierwszej iteracji grafik chciał bym zamienił ten kod na:

<nav>
  <ul>
    <li><a href=#>
      <span class="before_a"></span>Anchor Text<span class="after_a"></span>
    </a></li>
    <li><a href=#>
      <span class="before_a"></span>Anchor Text<span class="after_a"></span>
    </a></li>
  </ul>
</nav>

Plan rozwiązuje problem wizualny, ponieważ dodatkowe klasy mają dwa różne background’y symulując zaokrąglone rogi oraz cień. Niestety takie rozwiązanie jest błędne ponieważ wprowadza ona warstwę prezentacji CSS do struktury dokumentu HTML.

Zaproponowałem wariant 1 z nowymi funkcjami CSS dostępnymi w współczesnych przeglądarkach. Na drugą iterację poszedł do dzieła border-radius oraz box-shadow, jednak IE nie wspiera żadnego z tych genialnych udoskonaleń z CSS3 :( Po długich przemyśleniach z klientem doszedłem do kompromisu:

• Rogi w buttonach są zaokrąglone minimalnie – 1px
• Zmiana buttona z zaokrąglonymi rogami na zwykły prostokąt pod IE jest akceptowana
• Shadow do buttona musi być w wszystkich przeglądarkach.

Ten kompromis pozwolił mi na stworzenie kodu bez mieszania struktury dokumentu z warstwą prezentacji. Następujący kod rozwiązuje problem:

ul.menu > li {
    background: #292929;
    border-radius: 4px;
    -moz-border-radius: 4px;
    -webkit-border-radius: 4px;
    display:block;
    float: left;
    height: 37px;
}

ul.menu > li > a {
    background: #000;
    border-radius: 4px;
    -moz-border-radius: 4px;
    -webkit-border-radius: 4px;
    display:block;
    height: 16px;
    margin: 0 1px 0 0;
    padding: 10px;
}

Stworzyłem dwa elementy o podobnych rozmiarach. Pierwszy li ma kolor tła #292929 i jest o 1px wyższy od elementu a. Dodatkowo element a ma margines 1px z prawej. Dzięki takiemu “trickowi” element będzie zakryty elementem a oprócz 1px z prawej oraz 1px z dołu.

Element li wizualnie robi za shadow dla elementu a. Wynik prac wygląda następująco(u góry wersja w współczesnych przeglądarkach, poniżej w IE):

Shadow minimalny, można wogle go przegapić tak samo jak same zaokrąglenie, ale grafik tak chciał ;p Niestety box-shadow będzie musiał poczekać zanim uda mi się jakiegoś klienta na niego namówić :(

Od piątej wersji aplikacje w PHP wreszcie mogły być pisane “profesjonalnie”. Niestety etykietka kiepskiego języka pozostała z powodu jego użytkowników, którzy piszą kod według starych, złych nawyków i kod ten później sprzedają jako PHP w wersji 5.x :(

Aby zmienić to programiści muszą zmienić swoje paradygmaty na programowanie zwinne – Agile – oraz programowanie zorientowane na testy – TDD. W tym poście spróbuje pokazać kilka sposób jak wdrożyć taki styl pisania w projektach opartych na frameworku Kohana w wersji 3.0

1. Instalacja PHPUnit

Aby zainstalować PHPUnit wystarczą dwa polecenia w konsoli:

pear channel-discover pear.phpunit.de
pear install phpunit/PHPUnit

Oczywiście żeby zadziałały musimy mieć w systemie zainstalowanego interpreter PHP oraz system zarządzania bibliotekami do PHP – PEAR. Jeżeli nie maq tego w naszym systemie można skorzystać z gotowego rozwiązania jakim jest pakiet XAMPP

2. Konfiguracja PHPUnit w Netbeans

Netbeans ma wbudowaną współpracę z PHPUnit. Jednak aby się cieszyć współpracą PHPUnit z Netbeans musimy skonfigurować parę opcji aby Netbeans wiedziało gdzie ma szukać PHPUnit.

Pierwszym krokiem jest podanie ścieżki do interpretera PHP. Wybieramy Tools -> Options i poajwia nam się okienko Options które jest pokazane na obrazku powyżej. Należy zaznaczyć zakładkę z logo PHP i  zakładce General w polu PHP 5 Interpreter wpisujemy ścieżkę do pliku php.exe

W drugim kroku podobnie jak wcześniej podajemy ścieżke do pliku, jednym tym razem do pliku phpunit.bat. Aby to zrobić zmieniamy zakładkę na Unit Testing i wpisujemy ścieżkę do pliku w polu PHPUnit script.

W trzecim i ostatnim kroku wracamy do zakładki General i klikamy w przycisk Add Folder. Pojawi nam się przeglądarka katalogów. Znajdujemy katalog z biblioteką PHPUnit i go dodajemy do listy Global Include Path.

Netbeans jest gotowy do pracy z podejściem TDD – Test Driven Development.

3. Połączenie PHPUnit z KohanaPHP v3

Obrazek prezentuje typową strukturę projektu Kohana v3. Jedyne co dodałem to katalog tests/ w katalogu application/. W katalogu tym będziemy przechowywać wszystkie pliki potrzebne do testowania. Aby rozpocząć pracę musimy powiedzieć Netbeans  o naszym katalogu z testami in spe. Naciskamy kombinacje Alt+F6 lub menu wybieramy Run-> Test Project (nazwa_projektu).

Powinno pojawić się okienko Select a directory for PHPUnit. Wybieramy nasz wcześniej stworzony katalog do testów. Netbeans podzieli nasz projekt na dwie części Source Files oraz Test Files. W Test Files musimy stworzyć plik konfiguracyjny XML – sic!

Tworzymy więc nowy plik XML o nazwie phpunit.xml

<phpunit bootstrap="bootstrap.php" colors="true">
    <testsuite name="ApplicationTestSuite">
        <directory>./classes</directory>
    </testsuite>
    <filter>
        <whitelist>
            <directory suffix=".php">../tests</directory>
            <exclude>
                <directory suffix="*">../cache</directory>
                <directory suffix="*">../config</directory>
                <directory suffix="*">../logs</directory>
                <directory suffix=".php">../views</directory>
                <file>../bootstrap.php</file>
            </exclude>
        </whitelist>
    </filter>
</phpunit>

W pliku podajemy katalog w którym będą znajdować się nasze testy – linijka 3. Katalog ten należy stworzyć w Test Files. Następnie podajemy listę katalogów i plików które mają być ignorowane podczas wykonywania testów – linijki od 8 do 14.

Gdy plik konfiguracyjny jest gotowy to pora stworzyć plik bootstrap.php w Test Files. Będzie on odpalany na początku procesu testującego i przygotowywał środowisko do ich odpalenia.

require_once 'PHPUnit/Framework.php';

error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 'On');

$application = '../';
$modules = '../../modules';
$system = '../../system';

define('EXT', '.php');
define('DOCROOT', realpath(dirname(__FILE__) . DIRECTORY_SEPARATOR . '../../..').DIRECTORY_SEPARATOR);

if ( ! is_dir($application) AND is_dir(DOCROOT.$application))
    $application = DOCROOT.$application;

if ( ! is_dir($modules) AND is_dir(DOCROOT.$modules))
    $modules = DOCROOT.$modules;

if ( ! is_dir($system) AND is_dir(DOCROOT.$system))
    $system = DOCROOT.$system;

define('APPPATH', realpath($application).DIRECTORY_SEPARATOR);
define('MODPATH', realpath($modules).DIRECTORY_SEPARATOR);
define('SYSPATH', realpath($system).DIRECTORY_SEPARATOR);
define('WEBPATH', 'http://icomet.local/');

unset($application, $modules, $system);

require SYSPATH.'base'.EXT;
require SYSPATH.'classes/kohana/core'.EXT;

if (is_file(APPPATH.'classes/kohana'.EXT))
    require APPPATH.'classes/kohana'.EXT;
else
    require SYSPATH.'classes/kohana'.EXT;

require APPPATH.'test_bootstrap'.EXT;

Jest to w głównej mierze kopia pliku index.php dostarczanego do Frameworka KohanaPHP. Istotna zmiana ma miejsce 37 gdzie nazwę pliku bootstrap zamieniłem na test_bootstrap.

Jest to spowodowane tym że chcemy by cały framework się odpalił, ale nie chcemy aby wynik aplikacji nie był wyświetlony na wyjściu. Dlatego robi kopie Kohanowego bootstrap i wywalamy wyświetlanie ostatnie linijki odpowiedzialne za wyświetlanie response.

Finalnie kod test_bootstrap.php powinien wyglądać mniej więcej tak:

date_default_timezone_set('Europe/Warsaw');
setlocale(LC_ALL, 'en_US.utf-8');
spl_autoload_register(array('Kohana', 'auto_load'));

ini_set('unserialize_callback_func', 'spl_autoload_call');

Kohana::init(array(
    'base_url'      => '/projectname/',
    'index_file'    => 'index.php',
    'charset'       => 'utf-8',
    'cache_dir'     => APPPATH.'/cache',
    'errors'        => TRUE,
    'profile'       => TRUE,
    'caching'       => FALSE
));

Kohana::$log->attach(new Kohana_Log_File(APPPATH.'logs'));

Kohana::$config->attach(new Kohana_Config_File);
Kohana::modules(array(
    'database'      => MODPATH.'database',   // Database access
    'my'        => MODPATH.'my',
));

Route::set('default', '(<controller>(/<action>(/<id>)))')
    ->defaults(array(
            'controller' => 'welcome',
            'action'     => 'index',
    )
);

Gotowe :)

4. Pierwszy test

Przed poważnym testowaniem należy przetestować skrypt do testowania :) Zrobimy to tworząc prosty test. W Test Files tworzymy katalog classes/ a w nim plik BasicTest.php

class BasicTest extends PHPUnit_Framework_TestCase
{
    public function test_assert_true()
    {
        $this->assertTrue(true);
    }
}

Test jest banalny :) sprawdzamy czy true jest równe true :) Jeżeli wszystko poszło dobrze to powinniśmy po wciśnięciu Alt+F6 otrzymać wynik

PHPUnit 3.4.11 by Sebastian Bergmann.
.
Time: 1 second, Memory: 4.50Mb
OK (1 test, 1 assertion)


5. Testowanie bazy danych

Zanim przejdę do bardziej zaawansowanych przykładów TDD chcę pokazać moje podejście do tworzenia modeli w frameworku KohanaPHP. W podstawowej wersji każdy model powinien składać się z dwóch klas:

• Klasy bramki (gateway) dostępu do modelu
• Klasy modelu

Oczywiście moja architektura bazuje na module database, więc trzeba się upewnić że w katalogu application/config/ znajduję się plik database.php z wpisanymi dwoma wartościami:

return array(
    'default' => array(
        'type'       => 'mysql',
        'connection' => array(
            'hostname'   => 'localhost',
            'username'   => 'root',
            'password'   => '',
            'persistent' => FALSE,
            'database'   => 'projekt_development'
        ),
        'table_prefix' => '',
        'charset'      => 'utf8',
        'caching'      => FALSE,
        'profiling'    => FALSE,
    ),
    'test' => array(
        'type'       => 'mysql',
        'connection' => array(
            'hostname'   => 'localhost',
            'username'   => 'root',
            'password'   => '',
            'persistent' => FALSE,
            'database'   => 'projekt_test',
        ),
        'table_prefix' => '',
        'charset'      => 'utf8',
        'caching'      => FALSE,
        'profiling'    => FALSE,
    ),
);

Aby nie powielać kodu zbudowałem klasę Model_Gateway po której będą dziedziczyć wszystkie inne bramki do modeli.

class Model_Gateway
{
    public $db;

    public function  __construct() {}
    public function set_db($database_schema) {}

}

Jednak zanim klasa zostanie zaimplementowana, przygotujemy testy do niej :) Tworzymy nową klasę testów Model_GatewayTest w Test Files classes/model/GatewayTest.php.

class Model_GatewayTest extends PHPUnit_Framework_TestCase
{
    protected $gateway;

    public function setUp()
    {
        parent::setUp();

        $this->gateway = new Model_Gateway();
    }

    public function test_get_db()
    {
        $this->assertType('Database', $this->gateway->db, '$database object must be instance of Database class');

        $this->assertEquals('default', $this->gateway->db->__toString(), 'database_schema should be equal to "default"');
    }

    public function test_set_db()
    {
        $this->gateway->set_db('test');

        $this->assertType('Database', $this->gateway->db, '$database object must be instance of Database class');

        $this->assertEquals('test', $this->gateway->db->__toString(), 'database_schema should be equal to "test"');
    }
}

Jest tutaj użyta specjalna metoda setUp, która jest odpalana przed każdym testem, przygotowując środowisko do testowania. Mamy dwa proste testy. Pora napisać kod który te testy przejdzie pomyślnie.

class Model_Gateway
{
    public $db;

    public function  __construct()
    {
        $this->set_db('default');
    }

    public function set_db($database_schema)
    {
        $this->db = Database::instance($database_schema);
    }
}

Teraz jak uruchomimy testy to otrzymamy wynik pozytywny :)

6. Osobna baza dla testow

Kolejnym krokiem jest stworzenie systemu automatycznego kopiowania struktury bazy development do bazy test, aby przed każdym testem baza była czyszczona. Do tego celu napisałem klasę TDD_AbstractTestCase i umieściłem ją w modules/my/TDD/ AbstractTestCase.php

class TDD_AbstractTestCase extends PHPUnit_Framework_TestCase
{
    protected $db_test_layer;

    public function setUp()
    {
        $this->db_test_layer = new TDD_Database_Layer();

        $this->db_test_layer->copy_db();
    }
}

Klasa jest prosta. Wyszystkie klasy testów będą ją rozszerzać aby zachować zasadę DRY (Don't Repeat Yourself). Jednak żeby działała potrzebna jest jeszcze jedna klasa odpowiedzialna za warstwę testowej bazy danych.

Klasa TDD_Database_Layer znajdować powinna się w modules/my/TDD/database/ layer.php

class TDD_Database_Layer
{
    /**
     * Kopiuje strukture bazy zrodlowej do bazy docelowej.
     * Parametry sa kluczami z tablicy w kohanowskiej konfiguracji bazy danych
     *
     * UWAGA:
     * Baza docelowa jest najpierw czyszczona
     *
     * @param string $db_schema_source
     * @param string $db_schema_destination
     */
    public function copy_db($db_schema_source = 'default', $db_schema_destination = 'test')
    {
        $this->drop_db($db_schema_destination);
        $this->create_db($db_schema_destination);

        $sqls_to_create_table = $this->get_sql_create_tables($db_schema_source);

        foreach ($sqls_to_create_table as $sql)
        {
            Database::instance($db_schema_destination)->query(Database::INSERT, $sql, false);
        }
    }

    protected function drop_db($db_schema)
    {
        $database = $this->get_db_name($db_schema);
        Database::instance()->query(Database::DELETE, 'DROP DATABASE ' . $database, false);
    }

    protected function create_db($db_schema)
    {
        $database = $this->get_db_name($db_schema);
        Database::instance()->query(Database::INSERT, 'CREATE DATABASE ' . $database, false);
    }

    protected function get_sql_create_tables($db_schema = 'default')
    {
        $tables = $this->get_tables($db_schema);
        $sqls_to_create_table = array();

        foreach ($tables as $table)
        {
            $sql_to_crate_table_result = Database::instance()->query(Database::SELECT, 'SHOW CREATE TABLE ' . $table, false);
            $sqls_to_create_table[] = $sql_to_crate_table_result->get('Create Table');
            $sqls_to_create_table[] = 'ALTER TABLE `'.$table.'` AUTO_INCREMENT=1';
        }

        return $sqls_to_create_table;
    }

    protected function get_tables($db_schema = 'default')
    {
        return Database::instance($db_schema)->list_tables();
    }

    protected function get_db_name($db_schema)
    {
        $database_config = Kohana_Config::instance()->load('database')->get($db_schema);

        return $database_config['connection']['database'];
    }
}

Wygląda na skąplikowane ale ważna jest tylko metoda copy_db(). Jest to jedyna metoda publiczna. Metoda ta kopiuje strukturę tabel wewnątrz bazy źródłowej ($db_schema_source) do bazy decolowej ($db_schema_destination). Baza docelowa przed wykonaniem kopii jest czyszczona, więc należy uważać funkcji z wielką uwagą.

7. Testowanie bramki do modelu

Ok jak wszystko jest już gotowe pora zabrać się za poważne kodowanie. Stworzymy bramkę do tabeli users w bazie danych. Struktura tej tabeli jest następująca:

CREATE TABLE `users` (
	`user_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
	`user_name` VARCHAR(50) NOT NULL,
	`user_email` VARCHAR(150) NOT NULL,
	`add_date` INT(10) UNSIGNED NOT NULL DEFAULT '0',
	`edit_date` INT(10) UNSIGNED NULL DEFAULT '0',
	PRIMARY KEY (`user_id`),
	UNIQUE INDEX `user_name` (`user_name`),
	UNIQUE INDEX `user_email` (`user_email`)
)
ENGINE=InnoDB;

Tworzymy ją w bazie z schematu default. w bazie testowej zostanie ona stworzona automatycznie dzięki wcześniejszemu skryptowi. Powiem nawet więcej :). Jeżeli zmienicie jej strukturę w bazie default to automatycznie testy zmienią także strukturę tabeli w bazie test.

Wracamy do bramki jej celem będzie implementacja następujących metod:

class Model_Gateway_User extends Model_Gateway
{
    private $table = 'users';

    public function add_user($user) {}
    public function find_user_by_id($user_id) {}
    public function find_all_users() {}
    public function update_user($user, $user_id) {}
    public function delete_user($user_id) {}

}

Pora napisać testy do tych funkcjonalności. Tworzymy nową klasę testów: Model_Gateway_UserTest:

class Model_Gateway_UserTest extends TDD_AbstractTestCase
{
    private $gateway_user;
    private $fixtures;

    public function setUp()
    {
        parent::setUp();

        $this->gateway_user = new Model_Gateway_User();
        $this->fixtures = array(
            'user_1' => array(
                'user_name'  => 'Jan',
                'user_email' => 'jan@kowalski.pl',
                'add_date'   => time(),
                'edit_date'  => NULL
            ),
            'user_2' => array(
                'user_name'  => 'Jas',
                'user_email' => 'jas@kowalski.pl',
                'add_date'   => time(),
                'edit_date'  => NULL
            ),
            'user_3' => array(
                'user_name'  => 'Adam',
                'user_email' => 'adam@kowalski.pl',
                'add_date'   => time(),
                'edit_date'  => NULL
            ),
        );

        $this->gateway_user->set_db('test');
    }

    public function test_find_user_by_id()
    {
        $this->gateway_user->add_user($this->fixtures['user_1']);
        $user_name = $this->fixtures['user_1']['user_name'];

        $user = $this->gateway_user->find_user_by_id(1);

        $this->assertEquals(1, $user->user_id, 'user_id should be 1. Given: '.$user->user_id);
        $this->assertEquals($user_name, $user->user_name, 'user_name should be '.$user_name.' Given '.$user->user_name);
    }

    public function test_find_all_users()
    {
        $this->gateway_user->add_user($this->fixtures['user_1']);
        $this->gateway_user->add_user($this->fixtures['user_2']);
        $this->gateway_user->add_user($this->fixtures['user_3']);

        $users = $this->gateway_user->find_all_users();

        $this->assertEquals(3, $users->count(), 'Number of users should be 3');
    }

    public function test_update_user()
    {
        $this->gateway_user->add_user($this->fixtures['user_1']);
        $update = array('user_name' => 'Tomek');

        $this->gateway_user->update_user($update, 1);
        $user = $this->gateway_user->find_user_by_id(1);

        $this->assertEquals($update['user_name'], $user->user_name);
    }

    public function test_delete_user()
    {
        $this->gateway_user->add_user($this->fixtures['user_1']);
        $this->gateway_user->add_user($this->fixtures['user_2']);
        $this->gateway_user->add_user($this->fixtures['user_3']);

        $users = $this->gateway_user->find_all_users();

        $this->assertEquals(3, $users->count(), 'Number of users should be 3');

        $this->gateway_user->delete_user(1);
        $users = $this->gateway_user->find_all_users();

        $this->assertEquals(2, $users->count(), 'Number of users should be 2');
    }
}

Kod testu wymaga refactoringu, ale o tym punkcie 8. Teraz pora napisać kod który te testy przejdzie.

class Model_Gateway_User extends Model_Gateway
{
    private $table = 'users';

    public function add_user($user)
    {
        if(is_array($user))
        {
            $columns = array_keys($user);
            $values = array_values($user);
        }

        $sql = DB::insert($this->table)->columns($columns)->values($values);
        $result = $this->db->query(Database::INSERT, $sql, false);
        $insert_id = $result[0];

        return $insert_id;
    }

    public function find_user_by_id($user_id)
    {
        $sql = DB::select()->from($this->table)->where('user_id', '=', $user_id);
        $result = $this->db->query(Database::SELECT, $sql, true);

        return $result->current();
    }

    public function find_all_users()
    {
        $sql = DB::select()->from($this->table);
        $result = $this->db->query(Database::SELECT, $sql, true);

        return $result;
    }

    public function update_user($user, $user_id)
    {
        $sql = DB::update($this->table)->set($user)->where('user_id', '=', $user_id);
        $result = $this->db->query(Database::UPDATE, $sql, false);

        return $result;
    }

    public function delete_user($user_id)
    {
        $sql = DB::delete($this->table)->where('user_id', '=', $user_id);
        $result = $this->db->query(Database::DELETE, $sql, false);

        return $result;
    }
}

Oczywiście kod testów jak i kodu który je przechodzi można poprawić. Co dokładnie? Na pewno zauważyliście że fragmenty kodu testów się powtarzają. Głównie dotyczy to kodu który dodaje nowe rekordy do bazy. Najlepiej zamienić powtarzający się kod na prywatną metodę i wykonać ją przed każdym testem, czyli w metodzie setUp(). O tym traktuje kolejny punkt.

8. Refactoring

Główną zaletą TDD jest brak obaw przed zmianą kodu. Jeżeli zmienimy kod i przejdzie on następnie testy to wiemy że nadal wszystko działa. Takie podejście do tworzenia kodu zachęca programistów do refactoringu, czyli poprawy jakości kodu. Jakość kodu to jego czytelność oraz wydajność.

Dzięki TDD możemy zmienić algorytmy odpowiedzialne za logikę biznesową bez obawy że coś zepsujemy dopóki kod przejdzie testy. Trzeba pamiętać że testy to nie święte krowy, które się napisze raz i potem się ich nie dotyka.

Testy powinny odzwierciedlać zmiany w aplikacji. Testy powinny być nieformalną dokumentacją co aplikacja ma robić. Jeżeli aplikacja będzie się zmieniać należy przepisać testy do nowych wymagań. Spowoduje to że aplikacja która wcześniej przechodziła testy, tym razem się wysypie. Będziemy musieli przepisać kod aplikacji pod nowe testy. Gdy już to nam się uda będziemy pewni że wszystko działa tak jak powinno.

TDD umożliwia poprawę czytelności kodu, ale same testy też należy pisać z zastosowań wszystkich zasad tworzenia czystego kodu. Jeżeli testy będą pisane tylko po to by były to programiści nie będą ich rozumieć do końca i będą się bać ich zmieniać, co spowoduje że staną się bezwartościowe.

W punkcie 7 pisałem że testy potrzebują małego rafactoringu aby stały się czytelniejsze. Pora na poprawkę:

class Model_Gateway_UserTest extends TDD_AbstractTestCase
{
    private $gateway_user;
    private $fixtures;

    public function setUp()
    {
        parent::setUp();

        $this->gateway_user = new Model_Gateway_User();
        $this->fixtures = array(
            'user_1' => array(
                'user_name'  => 'Jan',
                'user_email' => 'jan@kowalski.pl',
                'add_date'   => time(),
                'edit_date'  => NULL
            ),
            'user_2' => array(
                'user_name'  => 'Jas',
                'user_email' => 'jas@kowalski.pl',
                'add_date'   => time(),
                'edit_date'  => NULL
            ),
            'user_3' => array(
                'user_name'  => 'Adam',
                'user_email' => 'adam@kowalski.pl',
                'add_date'   => time(),
                'edit_date'  => NULL
            ),
        );

        $this->gateway_user->set_db('test');
        $this->set_fixtures();
    }

    private function set_fixtures()
    {
        $this->gateway_user->add_user($this->fixtures['user_1']);
        $this->gateway_user->add_user($this->fixtures['user_2']);
        $this->gateway_user->add_user($this->fixtures['user_3']);
    }

    public function test_find_user_by_id()
    {
        $user_name = $this->fixtures['user_1']['user_name'];

        $user = $this->gateway_user->find_user_by_id(1);

        $this->assertEquals(1, $user->user_id, 'user_id should be 1. Given: '.$user->user_id);
        $this->assertEquals($user_name, $user->user_name, 'user_name should be '.$user_name.' Given '.$user->user_name);
    }

    public function test_find_all_users()
    {
        $users = $this->gateway_user->find_all_users();

        $this->assertEquals(3, $users->count(), 'Number of users should be 3');
    }

    public function test_update_user()
    {
        $update = array('user_name' => 'Tomek');

        $this->gateway_user->update_user($update, 1);
        $user = $this->gateway_user->find_user_by_id(1);

        $this->assertEquals($update['user_name'], $user->user_name);
    }

    public function test_delete_user()
    {
        $users = $this->gateway_user->find_all_users();

        $this->assertEquals(3, $users->count(), 'Number of users should be 3');

        $this->gateway_user->delete_user(1);
        $users = $this->gateway_user->find_all_users();

        $this->assertEquals(2, $users->count(), 'Number of users should be 2');
    }
}

9. Nowa funkcjonalność w aplikacji

Ok jak już mamy w miarę czysty kod testów, pora przyjrzeć się metodzie add_user($user) oraz update_user($user, $user_id). Metody te nie sprawdzają czy zmienna $user posiada odpowiednie pary kolumna => wartosc które odpowiadają rzeczywistym parom z tabeli users w bazie danych. Pora napisać odpowiednie testy które opiszą takie sytuacje wykorzystania kodu.

class Model_Gateway_User extends Model_Gateway
{
    //[...]

    public function test_add_user_with_extra_data()
    {
        $add_user = array(
            'user_name'  => 'Andrzej',
            'user_email' => 'andrzej@kowalski.pl',
            'add_date'   => time(),
            'edit_date'  => NULL,
            'extra'      => 'extra_data'
        );

        $user_id = $this->gateway_user->add_user($add_user);
        $user = $this->gateway_user->find_user_by_id($user_id);

        $this->assertObjectNotHasAttribute('extra', $user);
    }

    public function test_add_user_without_full_data()
    {
        $add_user = array(
            'user_name'  => 'Andrzej',
            'user_email' => 'andrzej@kowalski.pl',
        );

        $user_id = $this->gateway_user->add_user($add_user);
        $user = $this->gateway_user->find_user_by_id($user_id);

        $this->assertAttributeGreaterThan(0, 'add_date', $user);
        $this->assertEquals(0, $user->edit_date);
    }

    //[...]
}

Jeżeli teraz uruchomimy testy, okaże się że niestety nasz kod ich nie spełnia :( Pora to naprawić. Najpierw się upewnimy że przed dodaniem usera jest ustawiona wartość add_date na aktualny timestamp. Dzięki temu przy dodawaniu będzie to automatycznie generowane i programista będzie miał o jeden problem mniej na głowie :)

class Model_Gateway_User extends Model_Gateway
{
    protected $table = 'users';

    public function add_user($user)
    {
        if(is_array($user))
        {
            $user = $this->set_user_default_data($user);
            $user = $this->filter_insert_data($this->table, $user);

            $columns = array_keys($user);
            $values = array_values($user);
        }

        $sql = DB::insert($this->table)->columns($columns)->values($values);
        $result = $this->db->query(Database::INSERT, $sql, false);
        $insert_id = $result[0];

        return $insert_id;
    }

    //[...]

    private function set_user_default_data($user)
    {
        if(is_array($user))
        {
            if(!array_key_exists('add_date', $user))
                $user['add_date'] = time();
        }

        return $user;
    }
}

Dodane zostały dwie funkcje set_user_default_data($user) oraz filter_insert_data($this->table, $user). Pierwsza została już zaimplementowana, jednak druga będzie wykorzystywana również w innych bramkach do modeli więc należy ją dodać do klasy Model_Gateway:

class Model_Gateway
{
    public $db;

    protected $table;

    //[...]    

    protected function filter_insert_data($table, $insert_data)
    {
        $columns = $this->db->list_columns($table);
        $filtered_insert_data = array();

        foreach($columns as $column)
        {
            if(array_key_exists($column, $insert_data))
            {
                $filtered_insert_data[$column] = $insert_data[$column];
            }
        }

        return $filtered_insert_data;
    }
}

Teraz testy zakończą się powodzeniem. Jak widać TDD nie tylko umożliwia poprawę kodu jego refactoring ale również dodanie nowych funkcjonalność do aplikacji jest mnie stresowe. Teraz gdy klient będzie chciał nowej funkcji bez problemu możesz ją dodać nie bojąc się że ta zmiana stworzy jakiś nowy bug :)

10. To dopiero początek :)

TDD to bardzo potężne narzędzie szczególnie w dużych projektach, gdzie dodanie nowej kolumny w tabeli zmiana całkowicie logikę aplikacji. To co pokazałem to lekki wstęp do tego co może TDD. Zachęcam do pogłębienia wiedzy w tym temacie bo naprawdę warto.

Na koniec 3 prawa TDD:

• Zasada 1. Nie wolno pisać kodu produkcyjnego, jeżeli nie ma napisanych testów które ten kod mogłyby pokryć.
• Zasada 2. Nie piszemy więcej testów jednostkowych niż wymaga do tego oblanie testu głównego. Błąd kompilacji jest równoznaczny z oblaniem testu.
• Zasada 3. Piszemy kod który te testy przejdzie pomyślnie i wracamy do zasady 1.

Skończyłem po długich bojach czytanie biblii na temat wzorców projektowych “Head First Design Patterns” w polskiej edycji wydanej przez Helion.

Książka napisana w bardzo przyjemny sposób z dozą humoru i genialnych rysunków. Na początku wydaję się, że książkę się przeczyta raz dwa bo jest bardzo zabawna i prosta w odbiorze. Nic bardziej mylnego. Książka ma pokaźną dawkę wiedzy i nie tak łatwo ją opanować w parę dni. Szczególnie że wiedza ta dotyczy bardzo trudnego tematu jakim są wzorce projektowe.

Od czasu jak pierwszy raz przeczytałem książkę “Wzorce projektowe – Analiza kodu sposobem na ich poznanie” to stałem się ich wielkim zwolennikiem. Niestety moja pierwsza lektura była opatrzona przykładami z dość ciężkim kodem Java. Był to rok 2006, a ja ledwo znałem OOP w PHP i ciężko było zrozumieć mi niektóre aspekty (tak serio to większość z nich :P).

Moja przygoda z wzorcami na dobre rozpoczęła się dopiero po pracy z Zend Framework który w sobie ma wiele zaimplementowanych różnych wzorców projektowych. Nie tylko same jądro tego frameworka jest wypełnione wzorcami. Niektóre biblioteki ZF wymagają znajomości wzorców na pewnym poziomie zaawansowanie.

Przykładem może być Zend_Form, system do tworzenia formularzy który sprawia wiele problemów phpowym noobom i zniechęca wiele osób do ZF. Wszystko jest spowodowane zastosowania wzorca projektowego Dekorator i sposób w jaki można dekorować wszystkie elementy formularza.

Ogólnie o wzorcach w PHP bardzo mało się pisze :( Wiekszość książek z tej dziedziny jest pisana dla programistów Java lub języków z rodziny “C”. Bez doświadczenia w tych językach ciężko zrozumieć dość abstrakcyjne pojęcia z dziedziny wzorców projektowych.

Autumn bridge autorstwa ~KARRR

Na szczęście Head First Design Patterns stworzył pomost do wiedzy dla biednych programistów PHP. Książka nie jest pisana w czystym języku Java, ale w pseudo języku Java, który jest wstanie zrozumieć każdy kto zna OOP w jakimkolwiek języku i dzięki temu może dojrzeć piękno wzorców. Książka przedstawia podstawowe wzorce takie jak Fabryka, Dekorator, Strategia czy Obserwator.

Wzorce są wyjaśnione bardzo prostym językiem z prostymi przykładami, czasami wydaje mi się że zbyt prostymi ;p Prawdziwa perełka jest jednak na końcu książki gdzie za pomocą połączenia poznanych wcześniej wzorców powstaje nowy, a jednocześnie jeden z najpopularniejszych wzorców na świecie MVC, czyli Model View Controller a następnie jego odmiana dla aplikacji WWW czyli Model 2.

Ogólnie bardzo dobra książka dla ludzi, którzy ledwo co słyszeli o samych wzorcach i chcieliby się dowiedzieć czegoś więcej. Dla bardziej zaawansowanych może trochę przynudzać ale i tak warto ją przeczytać. Książka oprócz usystematyzowania wiedzy dostarczy kilkunastogodzinnego ROTFLa :) Polecam.

Po achach i ochach nad Netbeans 6.8, zrobiło się gorąco w internecie na temat kierunku rozwoju Netbeans. Oczywiście mnie interesuje tylko część PHP, więc byłem ciekaw co jeszcze można dodać do IDE dla PHP. Już w w wersji 6.8 mieliśmy dobry refactoring, genialne podpowiadanie składni z okienkiem PHPDoc (Eclipse też to ma, ale tam okienko z PHPDoc jest tak małe że nie da się z tego nic wyczytać przy dłuższej dokumentacji). Połączenia z bazami danych z podpowiadaniem zapytań SQL, wsparcie PHPUnit, Symfony Framework czy obsługi różnych API, m.in. twittera to już funkcje z płatnych i drogich platform koderskich.

W 6.9 natomiast drużyna pracująca nad IDE wprowadziła nowe funkcje o których nie wiedziałem że się przydadzą do momentu aż ich nie zobaczyłem :) Ale najpierw o czymś co jest najczęściej podawane jako killer feature w 6.9 czyli wsparcie do Zend Framework. Bardzo fajne i intuicyjne GUI dla Zend_Tool. Niestety w w wersji 1 kamienia milowego nie działa dla projektów już istniejących, udało mi się załadować wsparcie tylko do nowych projektów.

Mimo, że bardzo lubie Zend Framework to większe wrażenie zrobiło na mnie ulepszenia w podpowiadaniu składni a dokładnie z wzbogaceniem bibliotek PHPDoc do Wyjątków, Iteratorów czy rozszerzeń takich jak mysqli. Ostatnią rzeczą jaką zauważyłem w nowej wersji są ustalenia formatowania kodu.

Teraz można ustalić gdzie mają być nawiasy klamrowe (tzn w tej samej linii czy następnej), jakie mają być w cięcia przy listowaniu elementów tablic. Najbardziej użyteczna funkcja to chya jednak wcięć przy kontynuacji(tzn. jak mają wyglądać wcięcia przy wykonywaniu poleceń łańców, często wykorzystywanych przy wzorcu projektowym Fabryka) Opcji jest naprawdę multum, oto lista opcji dotyczących wolnych linii w różnych miejscach oraz poniżej liczbę spacji:

Teraz już nie ma mowy że w zespole ktoś powie że nie dostosował się do zasad formatowania w grupie, ponieważ tak a nie inaczej IDE generuje mu kod. Prawdziwy raj dla maniaków standardów kodowania.

Final Fantasy to jedna z najpopularniejszych gier RPG na konsole. Uwielbiam tę serię za to, że każda kolejna edycja to całkowicie inny świat a jednocześnie genialny klimat pozostaje :) Poniżej lista najlepszych według mnie tapet z gier Final Fantasy.

Launchy to program do szybkiego uruchamiania aplikacji w systemie Windows. Jest on znacznie lepszy i wydajniejszy od starego Menu Start. Poniżej lista według mnie najlepszych skórek dla Launchy:

1. Panda Skin

Najbardziej kreatywna skórka dla Launchy którą widziałem. Ikonki aplikacji pojawiają się w chmurce a sama Panda jest poprostu cool:)

2. Cat Launchy Skin

Do domyślnej skorki został dodany kotek :) Niby nic wielkiego a znacznie ożywia cały system. Dla miłośników kotów skórka z kategorii muszę to mieć.

3. Fuzion Skin

Bardzo fajna skórka. Aktualnie z niej korzystam w domu. Jest trochę większa od innych, dlatego Launchy w tej skórce jest umiejscowiony u mnie na środku pulpitu (normalnie na dole pulpitu). Bardzo fajna, polecam!

4. Launchy Olivia

Olivia jest jedną z tych dość surowych ale ładnie się prezentujących skórek. Pasuje do schludnie wyglądając pulpitów. W przypadku jednak kreatywnych ludzi jest trochę odpychająca.

5. WMP10 Remix Launchy 2 Skin

Lubisz nowego Windows Media Player 10? To wtedy skórka może ci się spodobać. Dla wszystkich maniaków Microsoftu;p

Kilka dni temu Google wypuściło nowy produkt pod nazwą Google Buzz. Jest to w skrócie połączenie Gmaila z Twitterem ;p Jeżeli masz godzinkę wolnego zachęcam do wysłuchania konferencji z uruchomienia Google Buzz:

Z buzza można skorzystać przechodząc na stronę http://buzz.google.com/ gdzie czeka nas krotki 2 minutowy filmik zachęcający do skorzystania z Google Buzz:

Buzzowe dodatki do przeglądarek

Google Buzz Dla Google Chrome

Buzz It Dla Mozilla Firefox

Tips & Tricks do Google Buzz

W Google Buzz są dostępne wszystkie skróty klawiszowe z Gmaila. Tak więc aby przejść do następnego buzza wystarczy kliknąć n (next) a do poprzedniej p (previous). Jeżeli jednak nie interesuje nas jakiś buzz, to poprostu po zaznaczeniu wybieramy klawisz m (muted). Taki buzz się nie pojawi się nam w naszym kanale.

Google Buzz ląduje defaultowo w naszej skrzydce odbiorczej, niestety gdy bedziemy podążać za dużą listą osób które bazzują nasza skrzynka może się zapchać, a tego nie chcemy dlatego najlepiej stworzyć filtr. Podczas tworzenia filtru wybieramy zasadę zawiera słowa i wpisujemy label:buzz. Klikamy dalej i wybieramy pomiń folder Odebrane (Archiwizuj). Gotowe :)

Jak wam się znudzi Buzz to na dole gmaila jest link wyłącz buzz.