Test Driven Development (TDD) is a software development process that consist in writing unit tests for functionality that is going to be needed and once the test fails writing the code to make it pass. This process is repeated for every new feature or bug.

The most used tool for running unit tests for PHP applications is PHPUnit and is the one we are going to use. We are not going to go through the process of installation in this article.

Organizing tests

We will start by creating a folder for our tests. We probably already have a tests folder in our application root. If we didn’t have it we would have to create it. Inside that folder we are going to create two folders called models and controllers.

Our main suite will allow us to run all our tests with only one command. To create this suite we will create a file TestsSuites.php in our tests folder. This file will allow us to run all our application tests.

Zend_Db_Table is an implementation of the Table Data Gateway design pattern provided by the Zend Framework. It provides a set of methods and attributes useful for interacting with a database table, but can also be extended to provide custom functionality for your application.

In the simplest case you will only want to use the functionality already provided by Zend_Db_Table:

1
2
3
4
5
6
7
8
9
// PDO_MYSQL can be replaced for any of the databases supported by Zend Framework
$db = Zend_Db::factory('PDO_MYSQL', $options);

// Set the db adapter that will be used by default by instances of Zend_Db_Table
Zend_Db_Table::setDefaultAdapter($db);

// Create an instance that will work against a table named 'users'
// This is case sensitive and must match exactly the name of the table
$usersTable = new Zend_Db_Table('users');

Zend_Application is a class that provides an easy to use bootstrapping facility for your application. It also takes care of setting up the PHP environment and introduces autoloading by default.

Zend_Application requires a config file to work, so the first thing we need to do is create it. We will create the configuration file application/configs/application.ini with this content:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[production]

; Error reporting
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0

; Paths
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"

[development : production]

; Error reporting
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

This class allows lazy loading of classes upon request. This will in place prevent you from having to manually include the files that you will need in your application.

To use the autoloader you have to first include the file and then create an instance of it. This will usually be done in your bootstrapping class.

1
2
require_once 'Zend/Loader/Autoloader.php';
$autoloader = Zend_Loader_Autoloader::getInstance();

Once your autoloader is ready you can use any class you need without having to manually include the file it belongs to. For example, if after calling autoloader you had this line of code:

1
$frontController = Zend_Controller_Front::getInstance();

Zend framework will replace underscores (_) with directory separators (/) and look for the file Zend/Controller/Front in your include path(get_include_path()), if the file is found it will be loaded, if it is not found an error will be issued.

In most of the Internet applications there is a need to have a configuration file to store static information that the application needs to work. An very common example of this information is credentials to connect to a database.

There are a lot of ways you can store this information and make it accessible to the application. Zend framework includes four classes for parsing four different kind of configuration files: Zend_Config_Ini, Zend_Config_Json, Zend_Config_Xml and Zend_Config_Yaml. In this article we will focus on Zend_Config_Ini for parsing files in the INI format.

When I first saw this programming pattern I found very difficult to understand why would people want to make their code so confusing. When I finally understood why this is used I knew I had to write about it someday. Today is that day.

Self executing functions are useful because using them you avoid creating global variables that could interfere with other parts of your code.

To understand this better I will give three examples of how you pollute and avoid the pollution of the global space.

For the ones of you who didn’t know (I didn’t know either), Apache has a limit on the number of back references you can use when rewriting a URL.

For the people who don’t know I will explain what is a back reference when talking about apache rewrites.

When you do a rewrite of a URL using apache mod_rewrite you translate a URL into an actual resource that apache can find.

For my examples I will use the domain http://ncona.com. If I wanted that the URL http://ncona.com/file loaded the file other_file.html located in my web root I would use a rule like this one:

1
RewriteRule ^file$ /other_file.php

That is a static rewrite but you can also use back reference to make dynamic URLs:

1
RewriteRule ^product/([0-9]+)$ /product_details.php?id=$1

XSLT (Extensible Stylesheet Language Transformations) is a language used to transform XML documents. It is mostly used to transform an XML document into a different XML document with a different XML Schema.

XHTML (eXtensible HyperText Markup Language) is an XML version of the HTML markup language. It was created so websites could be parsed using standard XML processors instead of having to depend on specific HTML processors.

The problem

So far everything sounds good, but there are some problems. Following the standard you should be able (as a matter of fact you must) to send an XHTML document to the browser with a mime type of “application/xhtml+xml”. The problem here is that some browsers (IE) don’t understand that mime type and thus don’t render your document.

Git hooks

From git documentation:

Hooks are little scripts you can place in $GIT_DIR/hooks directory to trigger action at certain points. When git-init is run, a handful example hooks are copied in the hooks directory of the new repository, but by default they are all disabled. To enable a hook, make it executable with chmod +x.

If you take a look at your .git/hooks folder you will probably see a bunch of hooks created by default. In my current version of git all my hooks have a .sample extension. To make a hook executable you must remove .sample and make it executable. If you don’t want to remove the default example you can create a new file without .sample.

This post is basically a copy of pimping out git log. I just made some modifications to Bart’s alias to fit my personal preferences.

This code creates an alias named lg for the git:

1
git config --global alias.lg "log --graph --pretty=format:'%Cred%h -%C(yellow)%d%Creset %s %Cgreen(%ci) %C(bold blue)<%an>'"

Here is an explanation of what that command does:

1
git config --global alias.lg "..."