With Twitter moving its API to OAuth the idea of using tokens rather than passwords for authentication went mainstream. Many explanations of OAuth make it seem complicated whereas in reality the "OAuth Dance" is a series of simple steps executed in sequence. This talk covers consuming and providing OAuth services, includes implementation examples, and is recommended for all technical leads, architects, and integration specialists.

You can find Lorna's slides at http://www.slideshare.net/lornajane/oauth-7990565

                          

This year, the conference expands into a new dimension with the addition of a new sister conference, the Dutch Mobile Conference, running alongside DPC. All attendees will get access to both events. The addition of an additional strand to the conference is a response to the situation as we see it in industry. Our clients need mobile solutions alongside their web applications, and developers increasingly work across both web and mobile disciplines.

Call for Papers

The calls for papers for both events are open now and we'd be delighted to hear from you. You don't necessarily need previous speaking experience (but tell us if you have), you just need a great topic - and for these events, the more technical, the better! The URLs you need to submit your talk are http://www.phpconference.nl/call-for-papers and http://www.mobileconference.nl/call-for-papers - we can't wait to see what you come up with, but you need to be quick! The calls for papers close on Tuesday 31st January.

Come to the Conference!

Hopefully you've been enjoying our DPCRadio series, where we share the recordings from last year's PHP conference (if not, you can catch up on the DPCRadio page). This year will be bigger and better than ever, and we are sure you'll love the new mobile elements of the event as well - so come and join us, 7th-9th June in sunny* Amsterdam!

To follow along with the news from both events, follow our twitter accounts @DPCon and @DMConf.

* sunshine not guaranteed

                          

You already know Singleton, Signal/Observer, Factory and friends. But, which object oriented patterns are en vogue in the PHP world and how can you seize their power? This talk gives you an overview on Dependency Injection, Data Mapper and more OO patterns the PHP world talks about right know, using practical code examples.

You can find Toby's slides under "Advanced OOP Patterns" here: http://qafoo.com/presentations.html

                          

As developers, we typically think about the application domain problem and logic and then design our architecture and consequently the database tables from that. We see the database as merely holding the data and our programs as the part that applies logic and processing to that data. We develop our scripts in isolation from the rest of the finished system and rarely think about their impact on other processes and whether we are making good use of what PHP and MySQL are good at. There may sometimes be excellent reasons for this, but I suspect it is more often the case that:

• We are not really aware of what MySQL has to offer, or if we are we are not confident in how to use the features.
• The use of ORM (Object Relational Mapping) is growing and this tends to distance us from the actual database and the SQL. It is perfectly possible now to create an application without writing an SQL query at all.
• We like to keep control in our hands and using some of these features mean the database doing more and our code a lot less which feels threatening.
• We tend to develop in an isolated environment where the only thing running is our script; where we don’t have to worry about competing for resources and speed over a network. Increasingly our live applications are actually running on a network of servers and complex applications need all the help they can get to meet the requirements of page load times and to avoid contention for resources.
• As PHP developers we traditionally create a single web application with a database back-end that is just used for that application so re-use doesn’t seem such an issue. However modular or service-level applications are growing; I’ve worked with several of them in recent years.

If all our programs are doing are simple CRUD (Create, Read, Update and Delete) operations on single tables then just using the most basic features of MySQL is probably sufficient, but if it is more complicated then we could be missing out on features that will really improve the performance and resilience of our applications. We could also save overall development time through re-use of database elements. Our overall aim is to produce fast, reliable, robust applications and we let ourselves and our clients down if we don’t use all the tools at our disposal.

MySQL Tips and Features

So what are these features I’m referring to? I propose to review the options here and then cover a few of them in a bit more detail. I’ll start with the things that some of you may already be using and then move on to the more obscure. As a general rule the aims here are to move less data from database to program, to have each query execute as quickly as possible, and to keep our data as secure as we can.

Fetch a Limited Dataset

Limiting the number of columns you select, limiting the number of rows with LIMIT and careful use of the WHERE clause all reduce the amount of data being transferred. Another useful and often underused option is using the GROUP BY clause along with aggregate functions to read summary data, rather than reading a whole dataset and then performing calculations on it in your program. Imagine you want to get some summary information about a company’s departments and their members of staff. You could produce a query that reads all the staff records and then process that in your program, but a more efficient approach is to get MySQL to do it for you by using the GROUP BY feature.

Link Tables Efficiently

Use joins to read from two or more related tables at once. Inner joins, either explicitly using the JOIN keyword or by listing tables in a comma separated list, get all the records where there is a matching record in each table. Outer joins (LEFT or RIGHT) select all the records from one of the tables and then the values for the subsequent tables if found, or give NULL values if there are no matches. There is also a self join for those occasions when you need to compare the values in different rows of the same table. Joins are a key concept and well worth mastering if you are not already comfortable with them. What is less well known is that joins can also be useful when doing multiple table updates and deletes, although they are used implicitly with a comma separated list in this context rather than with the keyword JOIN.

Sub-queries can also be used in a number of ways to create complex queries that select data from a number of tables. There can be a lot of overlap with joins, in that often the same query can be written using either a join or a sub-query, and a join may well be more efficient. A sub-query can produce a scalar value for use in an expression, a column of single field results, a single row with several fields or a whole table of data that takes the place of a regular table. To find out more the mysql documentation is to be found at http://dev.mysql.com/doc/refman/5.5/en/subqueries.html.

Analyse Your Queries - Can They Be Improved?

Use MySQL's explain keyword when writing your queries to determine the most efficient way to write them when there are alternative ways of doing the same thing. EXPLAIN analyses the query and shows how many table rows have to be read to produce the output and which indices are used. Judicious use of indices can improve performance but poor use of them can actually make things worse, so they are worth giving careful thought to if you have sufficient access to/control of the database. Using EXPLAIN can also help you determine if changing the order of tables in a JOIN may improve the efficiency of a query.

It is very simple to use; when you think you have your query written, just run it with EXPLAIN in front of it. Then try some alternative ways of achieving the same output, or tweak the indices and compare the results.
eg.

EXPLAIN 
SELECT staff.name, department.name, grade 
FROM departments LEFT JOIN staff ON department.id = staff.department_id ;

Use Prepared Statements

Any security article covering PHP and MySQL will cover the desirability of using the prepared statements feature in PDO (PHP Data Objects) to guard against SQL injection. This is where the query is defined with place holders for changeable parameters which are then bound to it at execution. It also improves performance if the query is to be run a number of times with different data, as the query is only parsed when prepared rather than every time it is run as with a normal query repeated. I would view using these wherever possible as mandatory.

Transfer Data Efficiently

LOAD DATA INFILE (and the accompanying mysqlimport command line tool) is the most efficient way to insert a number of records into a table. Next time you need to do some sort of bulk import consider whether it is practical to have an appropriately formatted csv file transferred to the server (perhaps by FTP or equivalent ) and then use LOAD DATA INFILE to process it rather than reading it line-by-line in your script and inserting each record individually. You will have a much faster script that will have less impact on the server.

Enforce Data Consistency with Triggers and without Network Traffic

Triggers are defined statements that are run either before or after INSERT/UPDATE/DELETE operations on a table. They can be quite complex operations with the use of a block of statements and conditions. They can save the programmer having to remember to implement this logic each time the data is used and therefore help to force the integrity of the data. As an example, related records could also be deleted or updated to reflect the change or an entry created in an archive table when a record is deleted. They tend to have a bad reputation amongst developers; I suspect it is because they instinctively don’t like something they aren’t controlling. Perhaps if we thought of them in terms of the observer pattern we would be more at ease with them!
eg.

delimiter |
 
CREATE TRIGGER demo 
  BEFORE INSERT 
  ON t1
  FOR EACH ROW 
  BEGIN
    SET full_name = CONCAT(NEW.first_name, ' ', NEW.last_name);
    DELETE FROM t2 WHERE code = NEW.code;
  END;
|
 
delimiter ;

Pick the Right Database Engine for Your Tables

Database Engines are an important element to consider when designing a database. A default engine is set for a database, but can be changed per table. Think about what sort of table you are defining, and don’t just let MySQL default to the MYISAM engine. MYISAM tables are good for tables largely used for lookup and searches but if it is to be updated frequently the INNODB engine which comes with the option of transactions is a better choice as the use of transactions will improve data integrity.

Take Advantage of MySQL Views in Your Application

Views are stored select statements that can then be used in a query as if it was an ordinary table. They can select data from tables and also other views using most of the constructs available to any SELECT query. The only proviso is that there has to be some solid data behind it, so temporary constructs such as user variables and temporary tables are not available in views. The SELECT statement in the view is actually run when the view is used in a query; either the SELECT criteria merged with those of that query or run first to produce a temporary table which is then queried further by the end query.

Views can also be used to hide table structure changes, such as a table split into two. A view could be created with the old table name and effectively the same data, and then users would be able to query that as before without disruption.

Views particularly come into their own when reports are being generated. The view can be designed to select the base data the report(s) are based on, and then a report query can select and perform calculations based on this set of data - without the writer of that query having to know all the ins and outs of where the data is obtained. If the temporary table option is used then the underlying data tables are not being tied up for longer than necessary and are free for other users. A standard temporary table could be created for the same purposes but that has the disadvantage of being more likely to get out of date and using a view also means that the SQL for creating the "temporary table" is kept in the database and is accessible by all users with the relevant permission. Depending on the exact circumstances, this may or may not be appropriate.

To illustrate a view in action (although there are doubtless better ways of achieving what this does!)

CREATE ALGORITHM = TEMPTABLE VIEW engineering_staff (name, location, grade, manager_id) AS
SELECT CONCAT(staff.firstname, ' ', staff.lastname), department.location, staff.grade, staff.manager_id)
FROM department LEFT JOIN staff on department.id = staff.department_id
WHERE department.name = 'Engineering';
 
SELECT name, location, grade
FROM engineering_staff
WHERE grade > 5
ORDER BY grade;

If there is a clear one-to-one correlation between a view’s output rows and the underlying data then views can also be used in UPDATE and DELETE statements.

Procedures and Functions in MySQL

A few years ago, before joining Ibuildings, I spent some months working on a major application that used PHP with the Oracle database and the application made very heavy use of Oracle's procedures and functions; the SQL in the code itself was largely confined to call statements to use the procedures. This functionality was new to me as it wasn’t available in MySQL at that time (it was introduced with version 5), so MySQL developers don’t have a history of using these in the same way that users of other databases do.

The MySQL documentation defines a stored routine as:

A stored routine is a set of SQL statements that can be stored in the server. Once this has been done, clients don't need to keep reissuing the individual statements but can refer to the stored routine instead.

It is effectively a mini SQL program that is stored in the database; it has inputs, outputs and processing. Stored Routines is a term used to refer to two constructs that have many similarities but also some important differences.

Whilst MySQL provides a wide range of built in functions such as CONCAT() or YEAR(), it is also possible to write your own. Just like stored procedures, they can take input parameters and do some complicated processing but they must return a single value of a declared type. A function is used in an expression within an SQL statement just as the built-in functions are, for example:

SELECT id, name, MYFUNC(grade), dept FROM staff ORDER BY name;

A stored procedure is more complex, it has both input and output parameters and the results of a SELECT statement are returned to the calling code if not part of a cursor, just as with a standard SELECT query. It is actioned by using the CALL statement. Quite simply it would look like this:

CALL my_procedure();

What do Stored Procedures Have to Offer?

In a nutshell:

• You can write considerably more complicated SQL than in a simple query, expressing more complex logic. There are control structures available, such as if/else and loops. With cursors you can iterate through the output of a SELECT statement.
• By doing the logic processing within the database less data needs to be transferred from the database server, improving performance, although it does make more demands on the database server’s memory.
• There is error handling available, so a failure doesn’t have to be a show-stopper, improving robustness.
• The code can be re-used by a range of applications and each developer does not have to re-invent the wheel. With the use of parameters both in and out the procedures can be written to be context dependent, increasing their flexibility and usefulness.
• As with the client/server contract between classes the calling program doesn’t have to know how the database is organised so it is easier to change this without breaking applications or spending a considerable amount of time tracking down where the data is used.
• The procedure can be written to use the privileges of the user who creates it so enabling securer use of sensitive data which can be processed without being returned to the client and without the script’s users needing to have the level of privileges needed to access the data directly.

How to write a stored procedure is a tutorial subject in it's own right, so I don't propose to go into it here. The mysql documentation at http://dev.mysql.com/doc/refman/5.5/en/create-procedure.html is a useful starting point.

There are many different options for using MySQL with PHP; here I will give a quick example of calling a stored procedure from PHP using PDO, which is my preferred method. Suppose we had a stored procedure which takes an input string, does some clever stuff with some tables and then returns a single output value and a set of records from a select within the routine. In PHP you might see something like:

$db = new PDO('mysql:dbname=test;host=localhost', 'testuser', 'testpassword');
$data = $db->query("CALL my_procedure(‘input string’, @output);")
                  ->fetchAll(PDO::FETCH_ASSOC);
$output = $db->query("SELECT @output;")
                       ->fetchAll(PDO::FETCH_ASSOC);

Getting the results of the select will look familiar, but getting the output value is a bit more complicated this makes use of MySQL’s user variables - denoted by @. This can be initialised beforehand with a SET query (SET @output := 0;). However using it without prior initialisation will initialise it to null and then the procedure populates it with a value. To get the contents of a user variable you need to select it.

Making the Most of MySQL

Although this has been a lightening tour, I hope I've given you a taste of the features in MySQL that I'll be using in my applications in the future - and that I've whetted your appetite to find out more about them and to be more adventurous with MySQL. If there's a particular feature that you think belongs on the list, or you can personally recommend a tutorial site, then leave us a comment and tell us what it is and why!

                          

The web is full of useful advice focussed on pushing out the last bit of performance of your code. They mention trivial changes. like changing every occurrence of print with echo even suggesting to use for instead of foreach. These optimisations help, but you are not going to notice it unless they're in a tight loop with many iterations. It is also a wrong approach for tackling performance issues. Before you can optimise, you need to find out if your codeis actually slow; then you need to *understand* the code; and *then* you need to find out where you can optimise it. This talk introduces tools and concepts to optimise the optimisation of your PHP applications.

You can find Derick's talk slides over on his site [PDF]

                          

CouchDB is a prominent representative of the NoSQL movement. Using its integrated web server and eventual consistent replication you can not only distribute data, but also full application code. This even works for clients which are not always connected to the internet, like e.g. mobile devices. This session gives you an insight Couch apps, their beauty and pitfalls.

You can find Kore's slides over on http://talks.qafoo.com/

                          

This session starts with a brief but important overview about the growing Oracle technology eco-system. It shows what Oracle's direction means for PHP application development and deployment.

The majority of the talk then highlights techniques on building high performance PHP applications with the very widely used Oracle Database. Techniques include connection pooling, application monitoring, automatic data privacy for PHP application users, online application upgrades, caching for performance, and how to suspend and resume database transactions to effectively build stateful web applications.

You can find Chris' slides on oracle's technetwork

                          

Architectural and design patterns help software architects to break systems in to smaller, more maintainable sections organised by their functionality and usage. The biggest benefit of patterns is that someone has already solved problems we may face and by utilising patterns such as Transactional Script, Domain Model or Data Mapper in your application it gives us, as developers, some good guidelines on how it should be designed.

Now take a a look at the code in your current project. Is it as well organised as that workshop? Is every class grouped by its purpose, in a nicely organised directory structure? I suspect most of us will answer "just about" to these questions. Most web applications are built of various subsystems, where each one is responsible for different things, such as reading from and writing to a database, retrieving data from a feed, and so on. It's exactly the same as in the workshop, different parts of the system have different purposes; hence they should be grouped in layers. Think about a cake and how it is layered, with sponge at the bottom, jam and cream on the top.

Subsystems, with different responsibilities, are arranged in layers, where each one rests on the layer below it. Higher layers use APIs or services provided by the lower layer, however this lower layer is completely unaware of the fact that there is a layer above it - and it hides another lower placed layer from the layer above. Such architecture encourages separation and decreases coupling between different parts of a system.

There are three major layers in software architecture:

• presentation - the layer contains all the logic responsible for handling interactions between the systems and an user, whether by using GUI or command line. The layer is responsible for displaying information to the user and collecting user input that is passed to domain logic.
• domain - the domain logic layer is also referred as business logic. This layer is the workhorse of an application, it does all the work the application needs to do. The domain logic does calculations on users’ input or stored data. It passes the data to data source layer so it can be persist, furthermore, the layer validates input passed from the presentation layer.
• data source - the layer’s purpose is mainly to communicate with other systems, such as databases, messaging systems and transaction managers. In web applications the major communication will be with different database systems.

Now that we know what types of layers we can find in software architecture, let's have a look at how we can organize domain logic and data sources layers.

Organizing Domain Logic

There are three main design patterns that help us to organize domain logic; these are transaction script, table module and domain model. The following sections will take each of these patterns in turn and examine their suitability for application in various situations.

Transaction Script

The transaction script pattern is the simplest solution for organizing domain logic. There is a collection of scripts that are executed on a server, and every script handles a single procedure that corresponds to a specific request made by a user or another system. The procedure may involve taking user input from the presentation layer, validating it and then storing the data in a database or passing it to external services.

If you have been using PHP for a while, you may remember the way websites were built in the late 90s and around the beginning of the millennium. You had a massive set of scripts, named as guestbook.php, add_entry.php, and view_entry.php, and each of them did one job. In our example scripts, would present all guest book entries, add a new entry to the guest book and display one single entry.

Transaction script is an ideal solution for systems with only a small amount of logic, because it is very easily understood by developers, it has little performance overhead and it performs well with an elementary data source layer when put into action with patterns such as Row Data Gateway or Table Data Gateway. However, you will discover transaction script's disadvantages as soon as the complexity of your domain logic increases. Quite often various transactions must perform similar actions, which leads to duplication of code across them. Some of the code can be refactored into separate classes or functions, however it gets harder and harder to keep the application's structure well-organised as the complexity grows.

Table Module

The next design pattern for organizing domain logic is Table Module. It presents a database-centric approach; all the business logic is organised around database tables. In Table Module, a single class encapsulates all the domain logic for all records stored in a table or view. It's important to note that there is no translation of data between objects and rows, as it happens in Domain Model, hence implementation is relatively simple when compared to the Domain Model pattern (which is next on the list). Table Module provides an interface to perform operations on all the data, so every time there is a need to work on a particular row, a method expects some kind of identity reference to be passed as one of the parameters.

As mentioned before, Table Module is much simpler than Domain Model, making it an ideal middle ground solution between Transaction Script and Domain Model. With Table Module you gain much more structure and lower level of code duplication comparing to Transaction Script, because the domain logic is organized around tables rather than procedures. Table Module is an ideal candidate when an application makes heavy use of tabular data, which normally is a result of a SQL call, because it supports a Record Set pattern very well. However, if your application requires direct instance to instance relationship, then Domain Model will be much more appropriate choice as it better handles complicated domain logic.

Domain Model

The third and more complex solution for organizing domain logic is a design pattern called Domain Model. The pattern provides an object-oriented way of dealing with complicated logic. Instead of having one procedure that handles all business logic for a user action, there are multiple objects and each of them handles a slice of domain logic that is relevant to it. When you start building a model of your application's domain, which in fact is an abstract representation of reality, you will find that initial classes are organised essentially around the nouns in the domain. For instance, when you build an e-commerce solution you will end up with classes such as Customer, Basket, Category and Product; these are the first things you will discuss when thinking about the domain. In a nutshell, each of the classes will incorporate both the data, mainly represented in form of attributes, and all the behaviour that is related to that data. Additionally, Domain Model objects are usually in a one-to-one relationship with records in database tables.

Domain Model is built out of small, loose objects with elegant interfaces, that stay completely free of any external dependencies. Persisting data in Domain Model can be done by implementation of the Data Mapper pattern; this is a great fit, but it will raise the level of complexity. It helps to deal with highly complex business logic in well organised manner, however, it also requires an object-oriented paradigm shift from developers wanting to use it. In fact the Domain Model pattern has a very steep learning curve and the process itself may be very frustrating and time consuming for people new to a rich object model. They can find themselves in a situation where they spend more time jumping from class to class looking for the behaviour they are interested in.

Taking a decision on whether to use Domain Model is highly dependent on the complexity of the business logic. Domain Model handles increasing complexity very well, however, it may take months before developers are fully confident working with the pattern.

Choosing the right solution for domain logic of your application

So far we have looked at three architecture design patterns that will help you to organize domain logic. However, the big question is which pattern you should pick for your application. Unfortunately, there is no straight answer. The decision-making process will be mainly based on judging the complexity of the application's domain logic. The rule will be that you would pick Transaction Script for applications with a lower complexity level and Table Module or Domain Model for applications where the business logic is more demanding. In general you wouldn't use Domain Model pattern for systems with simple domain logic, because the cost of understanding it and complexity of data source exceeds the benefit of this pattern. At the same time you need to consider changing requirements and how they may influence your application. Transaction Script and Table Module will definitely hit a wall much faster than Domain Model when the complexity of the business logic is increased by adding more features. Below is a chart representing relationship between complexity of domain logic and effort needed to introduce new features.

Relationship between effort and complexity for different domain logic architecture design patterns.
Source: Patterns of Enterprise Application Architecture by Martin Fowler.

Remember that even after you take your decision there may be new requirements that could change the application's complexity. In such circumstances it may be worthwhile to upgrade your chosen pattern, for instance refactor Transaction Script to Domain Model. However it won't make sense, in most situations, to go from Domain Model to Transaction Script.

Remember also that there is no rule to say you have to pick one pattern only; you can combine them in your design. It is common to delegate some business logic to Transaction Script and then use Domain Model or Table Module for other domain logic.

Organizing Data Source Layer

The main purpose of the data source layer is to communicate with other systems and to retrieve/persist data. When working with PHP you will find that the data source layer will usually connect to some sort of database. It is desirable, as a good coding practise, to separate database access and all SQL queries from domain logic and place it in separate classes. In most cases classes are organised around the table structure of the database, with each class corresponding to a table. It’s worth mentioning that your choice of data source pattern will be affected by which design solution you chose for the domain logic. Let's have a look at some options:

Gateway

When classes are based on table structure of the database, they act as a gateway to the table, encapsulating the SQL and database connection from any domain logic or presentation. There are two types of gateways: Row Data Gateway and Table Data Gateway.

Row Data Gateway

A class implementing Row Data Gateway pattern contains only data source logic, such as database access and simple conversion from database to in-memory types. An object looks exactly like a record in a table or a view, with each column mapped to a property.

Row Data Gateway should never include any of the business logic. If that's the case then it really an Active Record pattern instead.

Table Data Gateway

An instance of Table Data Gateway handles and encapsulates all the SQL used to access and modify all the rows in a single table or a view. The class usually provides a simple interface that includes multiple methods for finding data based on a condition, as well as some insert, update and delete methods. Each of the methods will map input parameters into SQL queries and then execute them against database connection.

Table Data Gateway always creates a record set when it returns data retrieved from database, even when there was just a simple find by primary key method executed. That makes the pattern very well suited to work with the Table Module pattern.

Editor's Note: Keep reading for code examples including Table Data Gateway.

Data Mapper

Very often, domain objects will have some attributes, for instance collections, that are not part of the database schema. This mismatch requires some sort of mechanism that helps structuring and transferring data between the domain logic and the database. This is exactly what Data Mapper does - it is a layer that separates the business logic from the database by moving data from one to the other. A simple implementation of Data Mapper would just map table columns to equivalent attributes of a domain class.

The great benefit of using Data Mapper is the fact that domain objects don't need to know that there is a database present, making it easy to introduce changes to database structure or domain logic. Additionally, the entire Data Mapper layer can be easily substituted with mocks and stubs for testing purposes.

Data Mapper is mostly used together with Domain Model, and we will go on to look at a code example of using these together.

Patterns in Practise

I would like to present an example showing how you can combine Data Logic and Data Source using design patterns mentioned in the article. I will mainly focus on Domain Model, Data Mapper and Table Data Gateway patterns. For the purpose of this example lets assume that we need to build ecommerce web application.

Domain Model

While analysing requirements you will notice that there are few nouns you talk about repeatedly. It’s your Customer, a Product the customer looks for, and a Basket where the product gets added to by the customer. These three are your domain specific classes. Lets start writing some code:

namespace Store;
 
class Customer
{
    protected $id = 0;
    protected $name;
    protected $address;
}

namespace Store;
class Product
{
    protected $id = 0;
    protected $name;
    protected $description;
    protected $price;
}

namespace Store;
class Basket
{
    protected $id = 0;
 
    /**
     * @var ArrayObject collection of products added to basket
     */
    protected $products;
    protected $customer
}

Each of the above classes will include some business logic specific to its domain. The Customer class may have methods for managing shipping address and financial details, the Product class may have methods that calculate taxes or discounts, and so on . The key is to keep these classes small and compact.

Data Mapper

As mentioned before, Data Mapper is used to move data between layers. For the purpose of this example we will have three database tables customers, products and baskets. Based on our domain model we know that we need to feed data into three objects, so the mappers we create will map data from the customers table to the \Store\Customer class, from products to \Store\Product, and lastly, from baskets to \Store\Basket. Below is a starting point for \Store\Data\Mapper\Customer data mapper; all the other classes will look pretty similar at this early stage.

namespace Store\Data\Mapper;
 
class Customer
{
    /**
     * @var \ArrayObject
     */
    private $identityMap;
 
    /**
     * @var \Store\Data\Gateway
     */
    private $gateway;
 
    /**
     * By using dependency injection it is much easier to unit test your mapper
     *
     * @param \Store\Data\Gateway $gateway
     * @param \ArrayObject $identityMap
     * @return void
     */
    public function __construct(\Store\Data\Gateway $gateway, \ArrayObject $identityMap)
    {
        $this->gateway = $gateway;
        $this->identityMap = $identityMap;
    }
}

As you can see constructor takes two parameters, first is an instance of \Store\Data\Gateway that implements the Table Data Gateway pattern. I decided to use the pattern here because it provides additional separation, however, it is entirely up to you how to handle SQL. The second parameter is instance of ArrayObject that acts as an Identity Map, which is used by the mapper’s find methods to ensure that every object is loaded only once. Lets have a look how it works:

namespace Store\Data\Mapper;
 
class Customer
{
    ...
 
    /**
     * finds customer’s row by primary key
     *
     * @param int $id
     * @return \Store\Customer
     */
    public function find($id)
    {
        if ($this->identityMap->offsetExists($id)) {
            return $this->identityMap->offsetGet($id);
        }
        // By using Table Data Gateway we hide away all SQL
        $data = $this->gateway->find($id)->getFirstItem();
 
        $customer = new \Store\Customer;
 
        // Simple mapping of data from Db to Domain Model
        $customer->setId($id);
        $customer->setName($data['name']);
        $customer->setAddress($data['address']);
 
        // Store customer object in identity map
        $this->identityMap->offsetSet($id, $customer);
 
        // And return Customer object
        return $customer;
    }
}

The first thing the find method does is a check whether data has been already loaded from database. If not, the mapper gets the data by using Table Data Gateway and maps it to the domain object. In my example it's a very simple mapping which links column to attribute, however, you can implement more sophisticated, metadata based mapping should you need it.

Lets have a look at how data is persisted when using Domain Model and Data Mapper.

namespace Store\Data\Mapper;
 
class Customer
{
    ...
 
    /**
     * save
     *
     * @param \Store\Customer $customer
     * @return void
     */
    public function save(\Store\Customer $customer)
    {
        $data = array();
 
        // Simple mapping of domain model to table columns
        $data['name'] = $customer->getName();
        $data['address'] = $customer->getAddress();
 
        if ($customer->getId() > 0) {
            $this->gateway->update($data, $customer->getId());
        } else {
            $this->gateway->insert($data);
        }
    }
}

Data Mapper has a save() method that expects an object of the domain model, in this case \Store\Customer. Once again the mapper prepares data and passes it to the database using a Table Data Gateway pattern. The code here is for Customer only but the concept applies to all domain model objects.

I hope that above example will help you analyse the requirements of your next project, and if you decide that these patterns are a good fit, that you will be able to introduce Domain Model, Data Mapper and Table Data Gateway easily. Are you using these patterns or planning on using them for the next project? Leave us a comment and let us know where they fit in your current or future applications!

                          

Tutorial Day

The conference started on Friday with its first ever tutorial day. I attended the "Security" tutorial by Arne Blankerts as it's very relevant for the project I'm working on at the moment. The talk was very enjoyable, especially because for the first time someone put emphasis not only on the software security aspect, but also on the hardware and the physical access control policy. You can put all your efforts and apply all the best practices to make your software secure, but everything can vanish in a moment if anyone can access your data centre without restrictions. My colleague Marco Lopes has reviewed this tutorial in more detail in his PHPNW11 report.

The second tutorial I attended was "Maintainable Applications in PHP Using Components" by Stuart Herbert. It was his first time delivering this content and I have to say he did it in an awesome way. Despite the network connection problems we had (which delayed the tutorial a bit), we got along very well by the time everyone had their environment setup. Stuart's tutorial was full of hands-on code. This course was not only a lot of fun and laughs, but interesting content too. I'm looking forward to using Phix to create my components repository, maybe pairing its workflow with the chef-based one we are already adopting at Ibuildings. Definitely a thumbs up for Stuart's project.

Main Conference

Ian Barber delivered the PHPNW11 opening keynote - an inspiring talk that gave us all the motivation to get back on track and contribute more to the community.

The day continued with Ben Longden's talk on "REST and the Hypermedia Constraint: A Case Study". Ben showed us how constraints are not necessarily bad, but instead can help you improve the way you implement your software. Talking about REST, he clearly demonstrated how the Hypermedia constraint can be very useful for de-coupling the server, provisioning the information and the client consuming it, reiterating what is REST and what is a RESTful API.

Following this, I was in the mood for a bit of PHP internals - and who better than Derick Rethans to talk about them? The talk title "PHP Extensions, why and what?" as expected wasn't about how to write extensions but about what they are and how they differ from components (and why and when you should prefer them to anything else). A very insightful talk; I'm now eager to write my own extension, with a better understanding of how they can be improved and how conceptually they should be taken into account.

I started my afternoon with Alistair Stead's talk titled "Varnish your PHP application, make it fly!", trying to gather more information and key points to convince the client I'm currently working for that it's time to seriously think about replacing Squid in favour of Varnish. Alistair is probably one of my favourite speakers; he gave a very well presented talk that covered caching concepts, mechanics and how Varnish can make your life easier. The winning point for most of the audience, myself included, was showing some numbers and graphs from a real use case which left people drooling at the idea of getting the same results with a proper caching strategy implementation.

BDD is rapidly taking its place amongst the common list of developers' best practices. Ben Waine's talk titled "Acceptance & Integration Testing Using Behat" brought his experience directly from the Sky Bet company field where Behat is commonly used to coordinate BAs, testers and developers in the most effective way. The talk went through the use of Gherkin, the language Behat uses, to defining its test scenarios down to the Phabric library used to define fixtures "on the fly" - once again using Gherkin tables saving you the pain of dealing with it. It also maintains all the SQL scripts used. All in all, a lightweight, well-presented talk, good for those who are not that much into the BDD concept.

To complete the first day I attended Thijs Feryn's talk "CLI, the other SAPI". Why? Well, as a command line warrior I'm particularly interested in exploring PHP's potential as a command line tool. It emerged during the talk that using PHP from the command line is not just useful for batch processing or scripting, but also for a development tool, testing your models and your code behaviour straight from the command line - this is not to be underestimated. What I enjoyed most about the talk was Thijs' approach: he involved the audience in the talk, testing attendees' knowledge with some simple command line snippets and asking people for the expected results. This was one of my favourite talks; if you have the chance to see it in the future, don't miss it.

Day 2, Sunday, was perhaps not as good as Day 1 content-wise. In the end, I only went to two talks out of three, preferring to spend some time socialising with some of the speakers in the hotel lounge about different geeky topics.

The first talk I went to was "Feeling secure? - notes from the field" by Paul Lemon. As I'd already attended the security tutorial the day before, this was perhaps not so relevant for me. There also wasn't enough time to cover all the topics properly, so the speaker was forced to gloss over the slides rather than talk in detail.

To conclude the conference, I attended "Teaching (mostly) PHP" by Clinton Ingrams. Clinton brought his "in the field" experience about how to mentor and teach students programming, especially PHP programming in this case, presenting his teaching framework. During the presentation we debated the effectiveness of the framework and the taught concepts, as they don't necessarily reflect enterprise reality. The general idea and how he categorised the topics within his teaching module seemed reasonable, as generally keeping concepts simple and easy is important. However, I have to agree with the crowd, some of the examples seemed too simple particularly for final year university students who have already had some programming exposure.

Conclusion

The venue was great, ignoring the WiFi connectivity problems and the queue for the food. This was a very social event from day one, warm and funny with a horde of geeks trying to mix with "normal people" (yes, that can happen if you attend the PHPNW conference, so try not to miss it next year). The best thing about PHP conferences is knowledge-sharing; you won't leave without a hundred different thoughts and ideas of how to do things better. Once again - definitely a good time, both personally and professionally. If you weren't there, you missed out!

If you didn't make it to the conference, the PHPNW11 organisers will be releasing all the main talks from the conference as videos over the next months. Follow @phpnw11 on Twitter to be the first to hear when the videos are up.

                          

Security Tutorial

Beware of the dark side, Luke!

For the morning of the tutorial day at PHPNW11, I decided to attend "Beware of the dark side, Luke!", a security tutorial by Arne Blankerts. While web developers tend to give more emphasis to the security issues directly related with their application (such as XSS, CSRF, SQL injection or Session security), Arne's tutorial was very interesting because it focused also on direct machine access, remote OS access, installed software exploiting, and hardware exploits.

Security is not an absolute concept, it consists of layers. How secure your data is from someone who's trying to obtain it depends on the effort someone is willing to put in versus the time/money you're willing to spend preventing that access.

Local Access

This bring us to the first topic of the tutorial, data centre security. Even if you went all the way to prevent remote attacks, can your hosting provider guarantee that someone won't just be able to enter their data centre, and flee with your disk full of client data?

And consider this - if your data is valuable enough to someone, and you have a backup system powered by your hosting company, what if that system is shared by other clients? Can an attacker get a machine and backup service on the same hosting company as you, and use this machine to try to get data from the backup server?

The point here is that there's always something that someone can do to get to your data. How far you need to go to prevent that depends on whether the data is worth that amount of effort. So, the first step towards security is to decide where to host your application. If you deal with very sensitive data that is of great value, you'll probably want to go with a secure data centre, encrypted disks, non-shared backup servers and all data, sent and received, should be encrypted. It's up to you to decide if you need all of this, none of this, or something in between.

Remote Access

The tutorial then proceeded to remote access security. The first step is to disable password-based SSH login and only allow key-based login. This prevents brute force attacks to get your password. Of course, external root access should also be disabled - if you need root access, just give Sudo capabilities to a standard user, or use su.

Under no circumstances should you use FTP. The FTP protocol is very insecure; not only does it send all your data in plain text over the network, but it also sends your login credentials in plain text. It also uses random port numbers for communication, making it easier for an attacker to take over an existing connection and receive/send information to your server.

Apache and PHP

After this, we started taking a look at security from the Apache and PHP perspective. We discussed why PHP's safe_mode is broken and in fact makes you more vulnerable to security issues than protecting you. For this reason, safe_mode should never be on, and is scheduled to be dropped out of PHP soon. On the other hand open_basedir should always be used.

All software exposing, such as Apache version, PHP version, or even if your server is using Apache and PHP, should be hidden from someone accessing your server. Always set expose_php to off on your php.ini file.

If possible, use php-fpm instead of mod_php. It will give you not only security advantages, but also performance improvements. With mod_php every request will cause Apache to load PHP and all of its modules, even if those requests don't require PHP to prepare the response, as for example static pages, or static images. With php-fpm, a number of PHP processes are always running, ready to reply to Apache requests that happen to need PHP.

Hardware

From here, we moved into hardware issues. Custom hardware issues. Again, this is something that requires your data to have enough value to someone, that they will go all the way to get a piece of hardware into your system. One good example is a modified USB dongle that can be casually dropped on a desk and that eventually someone will plug into their computer, or be social engineered to do it. From this point on, a hacker can have access to that computer.

Web Application Security

Next we moved into the security issues that PHP web developers are more familiar with - the exploits an attacker can run directly into your application.

XSS

We started by taking a look at Cross Site Scripting attacks. XSS lets an attacker inject content into a page, allowing them to add JavaScript or HTML to the page. We looked into the three different XSS kinds of attacks, which are the DOM based, the non-persistent and the persistent.

Some rules of thumb to avoid being vulnerable to XSS attacks, include making sure to filter input for the right context, always escape output contextually, always prefer whitelisting to blacklisting, and never try to read user intentions and repair their input, which sometimes can make an attack even worse.

Sessions

After XSS, we dived into sessions, and possible attacks through sessions. First we looked into some problems with sessions, such as coming from an untrustworthy source, being outdated or belonging to a user other than the one we’re expecting. We also noted that PHP doesn’t validate session id, which means a session id can contain malicious characters or not point to an actual session.

We then looked into session fixation, where a session id may be provided via a link using PHPSESSID, via XSS by setting a cookie or via plugins like Flash which breaks JavaScript security. Ways to prevent session fixation include validating the session id manually (i.e. writing custom code for it), always changing session id with each status change, such as login, change of permissions, or restart of session. Never use the URL to pass a session id, always use cookies and if possible send the HttpOnly header to the browser.

Session Data

We then proceeded to discuss why session data should never be trusted. Unless specifically overridden, PHP stores all session data on the same path. This means that if your application is running in a shared hosting environment, an attacker sharing hosts with you can read and write to your session data, and this can even lead to code execution.

Session Hijacking

The most effective protection against session hijacking is probably fully switching to HTTPS. In case this is not possible, always use different session ids for HTTP and HTTPS.

CSRF

Typical protection against CSRF includes using tokens. But for the tokens to be safe, you must not use predictable seeds for your token. An md5 of time(), for example, is easy to fake. Assuming that there's a session when comparing the token with the one supposedly stored on the session, can allow for a CSRF attack, if you fail to check whether the session really contains a token.

Session Puzzling

This can happen if your application uses the same name for session variables in different contexts.

Captcha

Captchas are hard to read, and can be easily crowdsourced. They're also vulnerable to the same implementation failure mentioned regarding CSRF. If the code validates the provided value against a value that is supposed to be in the session without checking for its contents, an empty attempt to get into the page, without an active session, can pass the captcha validation.

Database

In addition to using prepared statements, always make sure field names, table names and sorting fields don’t come from user input, use associative arrays as whitelists for those situations. Always make sure the user can’t send values other than int when setting limits on the number of results.

Use PDO instead of the MySQL extension.

Passwords

Never store plain text passwords. Use salt when encrypting a password and reapply hashing multiple times. Do a quality check on user-supplied passwords. If possible, advise your users not to use common words or common words with characters replaced by numbers (for example replacing and O by 0 or an A by 4 and so on).

Clickjacking

And finally we took a look at clickjacking and ways to avoid it, such as setting X-FRAME-OPTIONS to deny for no iframe embedding, or setting it to SAMEORIGIN to allow only frames from the same host.

Web Services Tutorial

After lunch, I went to the Web Services tutorial, presented by Lorna Mitchell, one of the organisers of PHPNW11.

We started by defining what a web service is: a way for an application to communicate, allowing for integration with other applications, exposing data and/or functionality, letting you refactor your application without the need to change the way others communicate with it. This allows you to have a common API from where different front ends or even 3rd party applications can get data or functionality.

We then discussed JSON vs XML, and why it is preferable to provide both kinds of output if possible. After that, we defined ‘Heartbeat Method’, and what it is used for. It was established that without documentation, examples, and a help point, a Web Service isn’t helpful at all, as people won’t be able to use it.

We then got into HTTP status codes, HTTP verbs and how to use them correctly and in a RESTful way. Still on the subject of HTTP protocol, Lorna spoke of the correct use of HTTP headers and how web services should be stateless, and all information needed should be on the request. Then we looked into some types of web services such as RESTful, RPC (XML-RPC, JSON-RPC or Soap). We looked in more detail into REST resources and collections. On how hypermedia allows a service to be self-documented, and allows URLs to change because they are provided by the API itself.

After a session of questions and answers, the tutorial day was over and everyone headed over to the pre-conference social at Kro Piccadilly to meet other developers and tech people all around.

Day 1

The first conference day started with an outstanding keynote by Ian Barber, "How to Stand on the Shoulders of Giants". Ian spoke about how great ideas often come from the wish to solve a personal problem and not from the intention of creating something revolutionary. He also spoke about how innovation often builds upon the work of others, and how any of us can one day build something great, if we just keep trying to build the tools that will help us get where we want.

After the keynote, I decided to go to Sebastian Marek’s talk "Magic Behind the Numbers - Software Metrics in Practice". Sebastian spoke about metrics to evaluate the complexity of a software project. He presented ways to look for the complexity and try to reduce it. He spoke of sonar, php_depend, php_cpd, phploc, PHPMD and a lot of other tools that can help one get to the bottom of where complexity lies within their application. I then attended Sebastian Bergmann's talk on "PHP Tester’s Toolbox". Sebastian, the author of PHPUnit, covered various testing tools for PHP, reviewing their pros and cons and comparing them to PHPUnit.

After lunch, I went to see my colleague Alistair Stead's talk on "Varnish your PHP Application, Make it Fly!" in Track 2. Alistair went through Varnish’s configurations details, how the options one takes during the configuration relate to the type of website on which Varnish is being applied. He showed some actual stats on how Varnish can speed up a Magento ecommerce website, and gave some details on how to use both together.

After Alistair's talk, I headed to Track 1 to watch another Ibuildings colleague - Rowan Merewood’s talk on "Estimation or 'How To Dig Your Own Grave'", which ended up being one of the best of PHPNW11. Rowan’s computer was having issues connecting to the projector, and to make things worse, the previous talk in Track 1 went on longer than expected, leaving Rowan even less time to set things up. After a while the audience started being amused by all these attempts to make the laptop work with the projector, but the solution ended up being the switch of Rowan's laptop for Ben Longden’s MacBook Pro. For some more amusement of the audience, Ben's laptop seemed to be unable to show the slides in fullscreen and the remote control to change the slides wasn't working either. At this point, Rowan recruited Ian Barber to manually change the slides through the talk, and it was time to start. His presentation was flawless, a great choice of images, every detail was taken care of, to the point that his clothes matched the slide theme. The talk focused on how to make project estimates, and how to avoid some common pitfalls that often ruin estimates. During the talk, some Twitter users were rating it as one of the best of the conference, which I will have to agree with.

In the evening, there was an open tab at the hotel bar, where the more than 350 participants met for some drinks and some more PHP-related talks. Later, a few of us decided to take a walk around Manchester and get to know the city and some of its iconic locations such as the legendary Factory.

All photographs in this post copyright (c) Stuart Herbert

                          

With Google constantly pushing the customer expectations of searching, is it time to move away from our database full-text search in pursuit of a more targeted platform? Can implementing Solr offer more than an answer to a search? Implementing a search platform isn’t always suitable for all applications, but in this talk we’ll look at identifying the right search solution, choosing the best way to integrate it into our application and exploring all the benefits a search server can offer.

Edit: Paul's slides can be found at http://www.slideshare.net/paulmatthews86/search-with-solr

                          

Martin de Keijzer

Many people use Zend Framework for it's MVC implementation, but it has a lot of hidden gems. Internationalization (i18n) is one of them. We will look how you can create an application that will have the right languages, currencies, dates and times all based on the location of the visiting user. This session will take away a lot of headaches in international projects and will improve the quality in overall.

Edit: You can find Martin's slides on slideshare

                          

Helgi Þormar Þorbjörnsson

APIs are commonly an afterthought, like a hot tub awkwardly attached to a house — a shoehorned approach that produces a suboptimal app with scarce support that lacks documentation. In effect, APIs are the ugly stepchild of the Web.

This is a sad reality that we are faced with, because many companies make their living consuming third-party APIs and mixing in their own data to create amazing and interesting mashups. In the initial phases of development, there is rarely enough money to develop the app and its API. By the time there’s both demand and money, it can be hard to fit an API on top of the architecture in such a way that the whole thing won’t fall over. APIs should be first class citizens of the Web. Inconceivable? Possimpible? Not at all!

In this talk we will dive deeper into why APIs are an afterthought, how we can change that. We will also touch on how that can benefit your product down the line in terms of resource savings and infrastructure efficiency, as well as the impact it will have on your infrastructure.

This talk is inspired by my phpadvent article.

(You can find Helgi's slides over on Slideshare)

                          

PHPSpec is the first ever PHP BDD framework. It is a port of RSpec to PHP created back in 2007 by Pádraic Brady and Travis Swicegood. Development in this framework stopped for a while and was reignited last August (2010). PHPSpec can be installed via pear, using these commands:

$ sudo pear config-set preferred_state beta
$ sudo pear channel-discover pear.phpspec.net
$ sudo pear install --all-deps phpspec/PHPSpec

If you are accustomed to unit testing, here is a quick translation sheet for xUnit/xSpec terms:

• In xUnit we test; in xSpec we describe, so your class names begin with "Describe"
• In PHPSpec, the spec file for a class MyClass is named MyClassSpec.php
• In xUnit we group tests in a TestCase. In xSpec we have examples that are grouped into Contexts
• In xUnit each method is a test with the prefix test. In xSpec each method is an example, we use the prefix it
• In xUnit we assert that something work as expected. In xSpec we specify how it should work

We've used Gherkin and Behat to specify how our application is supposed to work. We use PHPSpec to specify the behaviour of our classes. To get you started, let's see a simple example showing this. We are building a class that greets the user with "Hello, World!". The GreeterSpec.php file would look like this:

class DescribeGreeter extends \PHPSpec\Context
{
    function before()
    {
        $this->greeter = $this->spec(new Greeter);
    }
 
    function itGreetsUsingAHelloWorldMessage()
    {
        $message = $this->greeter->greet();
        $message->should->be('Hello, World!');
    }
}

If you already have experience with Unit Testing, the above would look familiar to you. Note that instead of saying: $this->assertEquals('Hello, World!', $message) we say $message->should->be('Hello, World!'). We are describing how we want the behaviour to be, rather than testing it. The before() method is a setup method that would get run before any example is run; the spec() method is a decorator that wraps the object being tested so we call the expectations on the properties and methods results.

To run the spec we use the phpspec command:

$ phpspec GreeterSpec.php

First we run it and watch it fail. Then we write a Greeter class to satisfy the example.

PHPSpec and MVC

Going back to our Video Renting application. The newly released version (1.2beta) includes integration with Zend Framework which enables us to test the MVC (Model, View, Controller) components individually. When we test an MVC application, we should start with the view, because that's what our scenario describes:

The text "Revolution OS" was not found anywhere in the text of the current page

Let's keep all our specs in a folder called "spec". To write a view spec we first add a folder called views under the spec folder. In our example, this is a view that corresponds to the index action of the review controller. We need to create an IndexSpec.php for our index.phtml view, containing the following code:

namespace Review;
 
// SpecHelper contains the usual ZF bootstrap
// copied from public/index.php
require_once __DIR__ . '/../../SpecHelper.php';
 
use \PHPSpec\Context\Zend\View as ViewContext;
 
class DescribeIndex extends ViewContext
{
    function itRendersTheSelectedVideo()
    {
        $video = \Mockery::mock(
            'Application_Model_Video', array('getName' => 'Revolution OS'));
        $this->assign('video', $video);
        $this->render();
        $this->rendered->should->contain('Revolution OS');
    }
}

Notice that we namespaced our class with the name of the controller. In a modular Zend Framework application you would namespace with the module name and then controller name, e.g. Module\Controller.

If we run the spec we should see an error because we haven't met its description yet.

$ phpspec spec
E
 
Exceptions:
 
  1) Review\Index renders the selected video
     Failure\Exception: $this->runExamples($exampleGroup, $reporter);
     Zend_View_Exception: script 'review/index.phtml' not found in path (/private/var/www/renting/application/views/scripts/)
 
Finished in 0.004656 seconds
1 example, 1 exception

At this stage we need to create the view to deal with the error we saw. In this example, we will use Zend Tool, which creates the controller/action/view all in one go:

$ zf create controller Review
Creating a controller at /private/var/www/renting/application/controllers/ReviewController.php
Creating an index action method in controller Review
Creating a view script for the index action method at 
/private/var/www/renting/application/views/scripts/review/index.phtml
Updating project profile '/private/var/www/renting/.zfproject.xml'

Now instead of an error, our output shows that we have a failure:

$ phpspec spec
F
 
Failures:
 
  1) Review\Index renders the selected video
     Failure\Error: $this->rendered->should->contain('Revolution OS');
     expected to contain 'Revolution OS', found no match (using contain())
     # ./spec/views/review/IndexSpec.php:17
 
Finished in 0.005078 seconds
1 example, 1 failure

This output means that the view now exists, but it's not showing the described text. That's what we expect, since we haven't coded the view yet. Let's add some code to do so:

<?php echo $this->video->getName() ?>

It should now pass.

$ phpspec spec
.
 
Finished in 0.001043 seconds
1 example

That's progress! However Behat is still not happy, because our controller is not setting the model for the view yet. Let us turn our focus to the controller, and start by creating a controllers directory and adding a ReviewControllerSpec.php.

DescribeReviewController must extend \PHPSpec\Context\Zend\Controller. We also need to specify that our controller will send be accessed by POST and will create the model in it. The controller/action will be routed from "/review" and we can add an example to make sure the route work as expected.

 
require_once __DIR__ . '/../SpecHelper.php';
 
class DescribeReviewController extends \PHPSpec\Context\Zend\Controller
{
    function itShouldRouteTheReviewsPageToTheIndexAction()
    {
        $this->routeFor(array('controller' => 'review','action' => 'index'))
             ->should->be('/review');
    }
 
    function itShouldDispatchToTheReviewController()
    {
        $container = new \Yadif_Container(
            new \Zend_Config_Xml(APPLICATION_PATH . "/configs/objects.xml")
        );
 
        $mapper = \Mockery::mock('Application_Model_VideoMapper');
        $mapper->shouldReceive('find')->andReturn($container->videoModel)->with('1')->once();
        $container->videoMapper = $mapper;
        $this->_getZendTest()->bootstrap->getBootstrap()->setContainer($container);
 
        $this->post('/review', array('id' => '1'));
    }
}

We'll also want to add the code for the controller itself. Assuming you are using Yadif or another IoC (Inversion of Control) container, it would look like this:

 
class ReviewController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->video = $this->getMapper()->find($this->_request->id);
    }
 
    function getMapper()
    {
        $container = $this->getInvokeArg('bootstrap')->getContainer();
        return $container->getComponent('videoMapper');
    }
}

We'll see that this now passes, when we run:

$ phpspec spec
...
 
Finished in 0.005271 seconds
3 examples

This looks much healthier, but if we run Behat, it will still be unhappy. We need to pass real data to the view, and then Behat will point out that the next step now is to describe the model. We need to have the data of our selected movies so we can fetch our view properly. Testing the models should be focused on behaviour, rather than the mechanics of database access. We know Zend_Db works, we need to know if we have made mistakes in our model. We will therefore test for the validation, filtering and business rules that we keep in the model.

class DescribeVideo extends \PHPSpec\Context
{
    function before()
    {
        $this->video = $this->spec(new Application_Model_Video);
    }
 
    function itIsNotValidWithoutTheName()
    {
        $this->video->setName('');
        $this->video->shouldNot->beValid();
    }
}

We need to implement a isValid() method in the Video model. PHPSpec does not have a beValid matcher, but it will use predicate matchers and find a method isValid() by magic. Once the isValid() is implemented properly than the spec passes. You can do something similar if the form validation is stored in your (zend) forms. Also note the before() method that will be called before any example is run.

You can describe your mapper's behaviour by inspecting that it calls the Data Access Object (DAO) to fetch to or persist data from the models. At that point you can then add the DAO (e.g. DbTable, Rss, etc).

Should we Hit the Database?

In many cases you simply need to verify the business logic and not the database operation. Hitting the database consumes both time and resources, which will slow down the execution. There will be times where we need to expose some database behaviour or just feel more confident that our models work. In those cases we can use a Test Data Builder pattern (this is a topic on its own, and I will save it for another post).

If you run Behat again after the model specs pass, the view should be displaying the correct data, so your scenario should pass, and a new scenario will be failing. We use Behat to tell us what to do next, and so the outside-in cycle is begins again.

Final Thoughts

In BDD, developers are driven by the specification, rather than tests of things they haven’t written yet. That said, the goals of both TDD and BDD are basically the same: making sure the user gets what they want. BDD makes that focus more explicit, and uses a language that invites the user to write their tests as a specification.

Behat and PHPSpec sit at different levels in the Outside-in cycle. Behat provides the outermost layer, allowing the stakeholders and developers to collaborate. PHPSpec provides the inner layer, allowing the specification of how the classes will collaborate with each other.

                          

The Evolution from TDD to BDD

The idea of using the specification to drive the development is an evolution from Test-Driven Development, or TDD. TDD is the practice of writing a test before writing the code to be tested. This is an iterative process; you'd start with red (failing test), write just only enough code to make the result turn green (passing test), then remove or re-organise the code, without causing the test to fail, and start again. As the codebase grows, refactoring becomes the core of the process. TDD plays an important role in allowing the refactoring to happen, allowing good quality code to be passed on to QA.

BDD (Behaviour-Driven Development) emerged from Dan North's attempt to teach TDD. His pupils would often ask the same questions, and if you've been to talks about testing then you have probably heard these questions yourself:

What should I test? How should I name this test? What is a unit? Where do I start?

Dan concluded that a big part of the problem was the word test.

Because of the emphasis on test, developers tend to focus on class structure as opposed to how the system should behave. Ironically the focus on test moves developers away from TDD as it was intended. Quite often, because of the tendency to try to test everything, our tests end up tightly coupled with our implementation. If we change our code, we break our tests, even if the behaviour remains unchanged.

A Few Words on Words

If you run PHPUnit with the -- testdox switch, you'll see that the tests' names are printed in a human-readable form. This feature is inspired by a tool called agiledox developed by Chris Stevenson. In using this tool, Dan realised that he could name his tests in an expressive way, letting others know what he was testing. He started using the word should in the test name, and stopped calling it a test, replacing it by behaviour. Here is an example PHPUnit test case that uses should in the test name:

class PHPSpec_Matcher_BeAnInstanceOf
    extends PHPUnit_Framework_TestCase
{
	public function testShouldPassIfTheObjectNameIsInTheDescription () {
                $description = $this->matcher->getDescription();
		$this->assertSame("be an instance of 'Foo'", $description);
	}
 
	public function testShouldPassIfAMeaningfulFailureMessageIsReturned() {
		$this->assertSame(
                    "expected 'Foo', got 'Bar' (using beAnInstanceOf())",
                    $this->matcher->getFailureMessage()
                );
	}
 
	public function testShouldPassIfAMeaningfulNegativeFailureMessageIsReturned () {
		$this->assertSame(
                    "expected 'Bar' not to be 'Foo' (using beAnInstanceOf())",
                    $this->matcher->getNegativeFailureMessage()
                );
	}
}

This class lives in BeAnInstanceOfTest.php, and if we run PHPUnit with the --testdox switch:

$ phpunit --testdox BeAnInstanceOfTest.php

We get a nice report:

PHPSpec_Matcher_BeAnInstanceOf
 [x] Should pass if the object name is in the description
 [x] Should pass if a meaningful failure message if returned
 [x] Should pass if a meaningful failure message if returned

After this realisation, Dan North started writing a replacement for JUnit, called JBehave. JBehave introduced another important shift in vocabulary, reducing the traditional Four-Phase test process (setup, exercise, verify and teardown) pattern into three: Given/When/Then.

Software development is all about communication, and this pattern is more sensible for business analysts, testers and developers alike. Specifying behaviour in a common language means stakeholders can take part in the process by identifying and expressing the scenarios.

The Gherkin Language

Gherkin is the language and parser that was created to specify features, as a part of a BDD tool called Cucumber. The language defines the structure of a feature, setting a number of keywords that can be used to describe the feature. The structure contains:

• A title
• A story
• Scenarios
• Steps

A Title

We start by specifying a title. The title of the feature should describe the activity done by a stakeholder in the system. If we were building a software to manage a video club, we might have a feature to record the renting by the members.

Feature: Member rents video

Note that we chose the title "Member rents video". This indicate that without this feature a member cannot rent any video from the collection. It should not be a topic, or a theme, but an activity performed in the system. A vague, less descriptive name would be "Renting Management" or "Video renting feature". The title should make it explicit what functionality will be implemented.

A Story

The next thing is the user story (you can read an earlier techPortal article about user stories for more information). A story has 3 components to it: an actor, a behaviour and a reason, which outlines the value it brings to the stakeholders.

Feature: Member rents video
  As a video-club member
  I want to rent a video
  So that I can take it away with me and watch it conveniently at home

Requiring a "so that" clause not only forces the team to think about the reasons for needing this feature, but it also makes it clear that the feature is enough to deliver what we expect from this story.

Scenarios

Each scenario has a title and a series of steps. The title should distinguish the scenario from all others. By reading the title you should be able to quickly guess how this scenario is different from all others. The steps are a series of pre-conditions, events and results, defined using one or more Given/When/Then clauses.

 
# Content of file renting.feature
 
Feature: Members rents video
  As a video-club member
  I want to rent a video
  So that I can take it away with me and watch it conveniently at home
 
  Scenario: Renting single video from oldies section
    Given I am in the "review" page
      And the selected video is "Revolution OS"
     When I click on "Rent"
     Then "£2" is added to my total
 
  Scenario: Renting 3 videos from oldies promotion
    Given I am in the "review" page
      And "Revolution OS" is selected
      And "Blade Runner" is selected
      And "The Wall" is selected
     When I click on "Rent"
     Then "£5" is added to my total

Steps

Steps are the building blocks of scenarios where each of the blocks is a requirement. Given/When/Then steps are intentionally flexible and adaptable. They are there to support the communication between the business and development teams. As the conversation evolves and the understanding of the feature changes we can easily update them. Use Given to state pre-conditions or context; When to describe the interaction with the system and Then is there to describe the expected outcome. You can also use And to combine more conditions, interactions or outcomes, e.g. Given some condition And some other condition When I do something And I do something else Then I obtain this outcome And This also happens

Introducing Behat, Putting Gherkin to use in PHP

Once you have written your scenarios using Gherkin, you can automate these using a tool such as Behat. Behat is a tool inspired by Cucumber, and written in PHP by Konstantin Kudryashov. At the time of writing, Behat 2.0.3 has been released and the syntax for this version is used in the examples for this article.

First you need to get Behat installed on your system. It is available from PEAR and you can install it by doing the following:

$ sudo pear channel-discover pear.behat.org
$ sudo pear channel-discover pear.symfony.com
$ sudo pear install behat/gherkin-beta
$ sudo pear install behat/behat-beta

If you have behat 2.0.3 or greater, then you are ready to go.

$ behat --version
Behat version 2.0.3

Then navigate to your project root and initialise Behat. This will create the necessary directory structure.

$ cd /path/to/my/project
 
$ ls
application	docs		library		public
 
$ behat --init
+d features - place your *.feature files here
+d features/bootstrap - place bootstrap scripts and static files here
+f features/bootstrap/FeatureContext.php - place your feature related code here
 
$ ls
application	docs		features	library		public

Time to start adding features. Under the features directory create a new file and name it renting.feature and add the content of "Feature: Member rents video" to the file and save it. At this point, we can let Behat tell you what to do next:

$ behat

Running this command will result in Behat outputting the code you have to write in PHP for defining your steps, with a message saying "You can implement step definitions for undefined steps with these snippets:". Note that the names of the methods are based on the text in the Given/When/Then from the scenario steps created above:

    /**
     * @Given /^I am in the "([^"]*)" page$/
     */
    public function iAmInThePage($argument1)
    {
        throw new PendingException();
    }
 
    /**
     * @Given /^the selected video is "([^"]*)"$/
     */
    public function theSelectedVideoIs($argument1)
    {
        throw new PendingException();
    }
 
    /**
     * @When /^I click in "([^"]*)"$/
     */
    public function iClickIn($argument1)
    {
        throw new PendingException();
    }
 
    /**
     * @Then /^"([^"]*)" is added to my total$/
     */
    public function isAddedToMyTotal($argument1)
    {
        throw new PendingException();
    }
 
    /**
     * @Given /^"([^"]*)" is selected$/
     */
    public function isSelected($argument1)
    {
        throw new PendingException();
    }

Step Definition Styles

Now that Behat has generously provided the skeleton of your steps, you can add the code into it. The code should contain examples of how the system should behave. The beauty of Behat is that you can easily model the interaction with the user by using methods like visit($page), pressButton($button), clickLink($link). This is possible because of Mink, a layer on top of Behat that simulates the user interaction with the browser.

For newcomers to tools like Behat or Cucumber, their early questions tend to be:

what do I put in the steps? Should I connect to the database via hooks to populate the DB? Should I simulate the user interaction including previous steps to add some data?

David Chelimsky[1] identified three different approaches, or step definition styles, of what to put in the step definitions: Automated Browser, Simulated Browser or DMA (Direct Model Access). The first two styles can be accomplished in Behat by using Mink with a driver; either Sahi for the Automated Browser approach or Goutte for Simulated Browser. DMA can be achieved by accessing the models directly from the step definition to add or retrieve some data to or from the database.

I am going to use Mink with the default driver, Goutte, however if your pages have Javascript you should use the Sahi driver.

First lets create a RentingFeatureClass which will look like this:

 
use \Behat\Behat\Exception\PendingException,
    \Behat\Mink\Behat\Context\MinkContext;
 
class RentingFeatureContext extends MinkContext
{
    // steps snippets here...
}

There is just one more step to complete the setup. You need to add a behat.yml to add your context. By default, Behat sets FeatureContext.php as the default context and if you add your steps to that file instead, Behat would be running those. However since you want to add more and more features in separate files, this isn't the best approach. You can add subcontexts to the main feature context, however for the sake of simplify let's just tell Behat to run our context alone. Also we need to tell Mink where the base URL for our application is. Therefore in the root of your project directory, create a behat.yml with the following code:

default:
  context:
    parameters:
      start_url: http://renting.local/
    class:  RentingFeatureContext
 
renting:
  context:
    class:  RentingFeatureContext

If you run Behat again you should get

2 scenarios (2 pending)
10 steps (8 skipped, 2 pending)

Instead of:

2 scenarios (2 undefined)
10 steps (10 undefined)

Behat is now pointing to the first step:

  Scenario: Renting single video from oldies section
    Given I am in the "review" page
       TODO: write pending definition
    And the selected video is "Revolution OS"

You are now up and running. Start by adding some code in the first Given step:

    /**
     * @Given /^I am in the "([^"]*)" page$/
     */
    public function iAmInThePage($page)
    {
        $this->visit($page);
    }

Behat should now be showing green for the first step and point you to the next step:

  Scenario: Renting 3 videos from oldies promotion
    Given I in the "review" page
    And the selected video is "Revolution OS"
      TODO: write pending definition
    And "Blade Runner" is selected

At this point we can add a bit more context. The user has already selected some videos. Mink will use a PHPUnit assertion for this. In fact, you can use virtually any assertion family; SimpleTest would work just as well (Lime is not ideal however, because it doesn't throw exceptions).

    /**
     * @Given /^the selected video is "([^"]*)"$/
     */
    public function theSelectedVideoIs($videoName)
    {
        $this->assertPageContainsText($videoName);
    }

Great! Now we got our first failure. This might not seem like great news, but as we originally stated, it is the first step in the process.

Scenario: Renting single video from oldies section
    Given I am in the "review" page
    And the selected video is "Revolution OS"
      The text "Revolution OS" was not found anywhere in the text of the current page
    When I click in "Rent"

Once you get a failure in Behat, it is time to go deeper and at this point the true outside-in begins. So far we have used Behat to specify how our application would interact with the user. Now it's time to go to our classes and specify how they will work with each other.

This article introduced the idea of BDD and also showed how we can set up scenarios to describe our application and execute these with Behat. Keep watching techPortal for the follow-up article, which will cover how to specify class behaviour with PHPSpec.

References

1. Chelimsky, David. The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends. The Pragmatic Programmers

                          

For a project to succeed, there needs to be a process in place that gets information as early and often as possible, where decision making happens based on information available at any point in time. Agile methodologies favour face-to-face communication and use user stories to collect customer requirements and to respond faster to constantly changing requirements. Use of user stories eliminates a need of extensive upfront requirements gathering and writing comprehensive documentation, allowing to us spread the decision making across the duration of the project.

What is a User Story?

In short, a user story is a chunk of functionality that is valuable to a user or a customer of the software. In my opinion the most comprehensive definition of a user story was provided by Kent Beck and Martin Fowler in Planning Extreme Programming:

"The story is the unit of functionality in an XP project. We demonstrate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer, and small enough so that the programmers can build half a dozen in an iteration"

Introduction to User Stories

A user story is a short written description, told from the perspective of a user, used for planning the system and as a reminder to discuss with your customer the details of the functionality. User stories are traditionally hand-written on paper cards and only represent customer requirements instead of documenting them. A user story has three critical aspects:

• Card - as mentioned before a user story is written on a card. The main section includes title/name of a story and description that reminds everyone what the story is. It may optionally include notes such as reference number, estimated duration and priority. The card is handed to developers when the story is scheduled to be implemented.
• Conversation - all the requirements needed to complete a story are communicated from customer to developers through conversation, usually taking place during iteration planning. Any vital piece of information that helps to concisely explain the functionality can be written on the card as a reminder, but never a full specification.
• Confirmation - this component is the acceptance criteria. It will be used to determine when a story is complete and whether it meets the goal of users. Acceptance tests are communicated by customer at the beginning of an iteration, they help to ensure the software is fit for its intended purpose.

An example of the user story:

As an account owner, I want to check my balance online

How detailed it should be

The user stories document the high-level details of a feature; these should provide enough information to allow developers to make low-risk estimates of how long it will take to implement each feature. At a time of iteration planning, developers and customer will discuss in detail all requirements for each story. Additionally, developers can add some annotations on a story card based on the results of the discussion.

The user story must only include functional requirements that are valuable and visible to a user. The following example is not a good story:

The software will be written in PHP

There is no value for the users in this story, because users would not care about the technical aspect. Users are interested in a unit of functionality, an action they can perform, for instance their checking balance online.

How long it should be

A user story must be short and cover just one unit of functionality, it is just “a thing to do”, without going into details, which will be covered in communication with the customer in later. To understand the expectations of a user we use acceptance tests, written on the back of a story card. These are short and incomplete, they tell us how to test the story. The goal here is to communicate additional details so that developers know the scope of the story.

Writing User Stories

The most important aspect of writing user stories is the customer's involvement in the process; only he has the vision how the end product should function. The user story must be written in business language, without using technical jargon, and should state design goals, so that it is understandable to all involved. The customer can then prioritize the stories based on value they add. Moreover, a user story needs to concentrate on the who, what and why of the functionality, never on how. Below you can find a simple template for writing user stories, which you can follow:

Title
One line to help differentiate a story

Narrative
As a [user role] I want to [goal] so that [benefit]

Acceptance criteria

List of tests decided by a customer

Start by writing a title/name of a story. This is used by the team to differentiate the story from other stories. The title should describe an activity and be short enough to fit on 3"x5" sticky note when written with a marker.

The description in a form of As a [user role] I want to [goal] so that [benefit] has many useful features. It implies that all users of the system need to be kept in mind, that developers must take into account what users want to achieve, and that developers need to convert that into a feature that users can benefit from. Additionally, it makes the story writer consider who wants the feature and why. Describing things in this form allows us to communicate the requirement to developers to help them understand it, and it also encourages further collaboration with the customer.

If you struggle to fit the description on a user story card, it is a good indication that narrative may be too long. The story may need splitting into several smaller stories, or it may need to include fewer details.

It is also good to include acceptance tests, which make the story easier to remember and help the team to understand what “done” means.

INVEST

The acronym INVEST stands for six attributes of a good user story, which ideally should be Independent, Negotiable, Valuable, Estimatable, Small and Testable. This next section describes each of these in turn.

Independent
When you write a user story you should take care to avoid introducing dependencies between stories. Each user story should be a self-contained feature that adds incremental value. Any dependencies created at the story-writing phase will lead to complications while prioritising stories and planning the next iteration.

Every so often, we will find that we cannot avoid having stories depend on one another, for instance you have three stories that each implements different type of payment method. You know that work on the first of these stories will take up to four days, with one additional day for the second and third stories. In such a situation, with highly dependent stories, it is not clear which story should be given the four day estimate. The solution to the problem is to revise these stories and combine them into one bigger (but independent) story, eg:

As a user I want to make a payment using methods X, Y and Z

If a story becomes so big that it is not possible to finish it within an iteration, you need to look for other ways of splitting the stories. In our example, we could instead split these stories into two new ones:

As a user I want to make a payment with primary method X
As a user I want to make a payment with additional payment methods Y and Z

If you cannot find a way of combining or splitting dependent stories, a fallback option is to write two estimates on a card; four days for if the story is implemented as the first one, and a one day estimate for if the story is done after.

Negotiable

As I mentioned before, user stories serve as a reminder to have a conversation with your customer about required functionality. The user story card consists of a phrase, in a form of title or description, that aims to remind you to hold the conversation, and has notes clarifying what aspects need to be resolved during conversation. In the process of communication, user story details can be changed or new requirements added. It is important to note that user stories are not contracts, changing them should be flexible up until they become part of an iteration.

Valuable

The feature described by a user story must add business value, meaning that the functionality should be significant to the end user or customer. It is worth mentioning here that not all user stories need to be beneficial to end user of the system. There are many situations where the technical aspects are vital for the customer, for instance the system is distributed across multiple locations and the system purchaser needs to have central point of configuration. In this instance, your story would look something like this:

As an administrator I want to have centralised configuration so I can remotely change settings across all units

The end users do not care where and how system is configured as long as they can use the system without disruptions. However, having a centralized configuration panel saves your customer a lot of valuable time.

How can you guarantee that all user stories are valuable to end user or customer? The solution is to make sure that the customer writes the stories, he is the domain expert and in the best position to specify the required functionality of the end product.

Estimatable

The user stories are written by the customer, but it is the developers' task to estimate the size or amount of time it takes to implement a story based on its complexity. Developers must always be in a position to estimate the story, based on the story’s narrative and any additional notes found on the story card. However, sometimes the development team is not able to estimate a story, usually as a result of one of these three situations:

• Development team lacks domain expertise. If this happens, developers must talk to the customer who wrote the story and discuss the functionality in more detail to obtain overall understanding of what is necessary. Not all details need to be understood by developers at the time of estimating, but they need to know enough to enable the team to estimate the story.
• Development team lacks technical knowledge. The customer may require the developers to use an unfamiliar technology. It is nearly impossible to make accurate estimates in these cases. Agile Programming provides us with a strategy for this called spike. A spike is a short experiment, with a defined maximum time frame, performed by developers with the goal to learn just enough so they can provide an estimate for the story. When using spike, you create an additional story for the spike itself and the estimate is the maximum time frame allowed for the experiment.
• Story is too big. The team may not be able to estimate the story when it is too big. The only solution is to split the story in to smaller, more manageable chunks of functionality and estimate each new story independently.

Small

User stories should be appropriately sized for the project environment. If stories are too small or too big, it makes estimating, prioritizing and iteration planning with any certainty very difficult. To determine the "right" size of story, you must consider the development team, its experience and capabilities, and the technologies in use. To adjust stories to right size you can split epic stories into smaller chunks of functionality or combine small stories into a bigger one.

Testable

Developers must know when work on a user story can be considered "done". The only indicators of "done" are clearly defined acceptance criteria. All tests should be written up front, before work on the story begins. As I already mentioned, acceptance tests should be written by your customer. When the customer struggles to clearly define how a feature should be tested, it may indicate an issue. The story may be overly complex or unclear, it may not have enough value, or simply the customer may require some help in defining tests.

Collecting User Stories

Gathering requirements in a form of user stories is an iterative process. On the first pass you gather the main requirements, to give you the feel of overall system functionality. The first user stories are usually the most valuable to the customer, moreover, they do not need to be clearly define at this point. Some stories can work as a placeholder to remind everyone to have a conversation in the future, for instance you can write following story:

As a user I want to search for products

simply because that is all you know at the time. Later the story can evolve and be redefined as a collection of smaller, more concrete stories. Every next iteration will bring smaller and smaller stories, some of them grow or decrease in importance after each iteration. Additionally you can find that lots of stories are missed in first few iterations.

The goal of an iterative approach to writing stories is to get very quickly requirements for a large chunk of a system and have an overall feel how big the application will be, in advance of starting to work on it.

Agile Development provides a set of techniques for collecting user stories that support evolving nature of them. These are:

• User Interviews - this is usually the default approach to gathering stories. The most important aspect of these interviews is to have a good selection of users, preferably performing different roles when using an application.
• Questionnaires - these are a very effective tool to gather additional details about stories you already have or how to prioritize them. Questionnaires also allow you to easily collect information from large number of users. This approach is inappropriate for gathering initial user stories, because they are one way communication channel and do not lend themselves to follow up conversation.
• Observation - Agile development guarantees that softwared is release as early as possible; you can use that fact and observe your user when they use the application. This gives you instant feedback how the experience can be improved.
• Story Writing Workshop - this is a meeting involving all players with an interest in the project; the product customer, developers and end users. During the workshop the team should only focus on brainstorming ideas and writing the stories, the customer will be able to prioritise all of them at later stage. In the story writing workshop, the goal is quantity of collected stories over the quality. Do not spend much time discussing a story, but make use of the fact that you have entire team in one room and cover as many aspects as you can. Note all stories on paper cards, even when you will later store them electronically, as it speeds up the process. Moreover, some stories may get abandoned as a result of discussion. This technique is a very effective way to rapidly gather initial collection of user stories.

The Distinction Between a User Story and a Use Case

The basic difference between user story and use case is in the perspective and the intent, which affects the level of captured details.

Use cases focus on the interactions between a system and one or more actors, where an actor can be a user or another system. Use cases describe a process and its steps in sufficient detail they can be understood on their own. The description of interactions is usually in a call-and-response format.

On the other hand, the user story concentrates on the users' values and is much lighter than a use case. It provides just enough detail so that a reader can understand the overall functionality that this user story should accomplish. A use of everyday language is encouraged to make sure user story is understandable by both developers and customers. In contrast to the use case, a user story is a reminder to have a conversation with your customer.

Summary

So why would you go to the trouble of dropping your current processes and instead use user stories to collect system requirements? Well, user stories emphasise collaboration with your customer, they encourage a verbal communication rather than tons of documentation. The ensure that the developers and the customer will interpret a statement in the same way. Since all user stories should be estimatable, it makes it very easy to use them in project planning; they are also small enough that you can fit few of them in one iteration. Finally, user stories are collected in iterative process, giving you the flexibility to add, change and drop requirements as your project progresses.

                          

This year as part of the Ibuildings team I attended the Dutch PHP Conference for the first time. What can I say? Well, it was an unbelievable experience; I enjoyed every moment spent there. I found it good first of all for the big names of the involved people such as Sebastian Bergmann, Derick Rethans, Fabien Potencier, Enrico Zimuel plus many others. There was also the high quality of the presented talks, but also for the great opportunity to spend good time with my colleagues at Ibuildings and people from other companies all around the world.

Day 2 started with Helgi Þormar Þorbjörnsson's keynote about First Class APIs development, why the API should become a first class citizen in the company development strategy, how to achieve this results in the most effective way possible and what the benefits from this approach can be.

After that I needed to decide which talks to go to and this decision was anything but simple because most of them were very interesting, not forgetting the uncon submissions that were very good too.

I chose first Profiling PHP Applications by Derick Rethans, who is known to be the father of Xdebug, possibly one of the best friends of all the PHP developers out there. The interesting thing in his talk has been not only the way he introduced and talked about profiling with Xdebug, but finally for the first time I enjoyed listening someone mention and talk also XHProf, a tool too many times not properly considered but actually very good especially when you need to profile production environment because of its low impact.

The second talk I attended has been Managing a shared MySQL Farm by Thijs Feryn, has the title can suggest you he basically presented a use case and a practical solution about how it’s possible to manage a shared MySQL farm with databases distributed on many servers, basics concept related to the standard MySQL user management and the problems you encounter when you have to spread those information across the network. I very much appreciated the comprehensive and complete explanation about using phpMyAdmin on the top of all the provisioning and management system using PMA Single Signon module and custom fallback function to determine database and nodes and properly switch to them.

Next I saw Modular Application Architecture by Kore Nordmann and Tobias Schlitt, which was interesting as two speakers presented at the same time. The talk was mainly focused on how to achieve code maintainability. So they introduced different solutions and different approaches exposing pros and cons for each one, topped with a good number of code examples.

Last (but not least!) Large-Scale Data Processing with Hadoop and PHP by David Zülke about map reducing implementation, how it can be used and how good it can be when you need to deal with huge amount of data. He introduced his talk with some numbers from Facebook, Yahoo and Twitter, numbers that can really make your eyes water! While Map Reduce itself is not really a new concept, this talk covered hadoop which is a framework to make working with map reduce much easier. What’s cool with it? Well it works with streams and it uses STDIN and STDOUT, which means that even though it is written in Java, you can use it with any language you like able to deal with streams. Luckily for us David already did the hard work for us writing "HadooPHP" (I'll let you guess what it does).

Overall Impressions

One thing I really appreciated about DPC was the Open Source and Open Knowledge spirit found there. Speakers were not there just only to talk and present something, they were there more to share their own knowledge and to share ideas and maybe a new solution to their problems. This, in my opinion, is one of the best things I took with me from DPC.

In the end I had an excellent time, both personally and professionally. If you weren’t there, you missed out!

                          

For the morning of tutorial day, I chose to attend Think like an ant, distribute the workload, given by Helgi Þormar Þorbjörnsson. Helgi is a former Ibuildings colleague and now a bigshot at Orchestra.io. I'm happy to see he's doing well. His presentation started off explaining to us why distributing can be a good thing by pointing out three significant aspects: budget, efficiency and perception.

Budget-wise, for a distributed application there is no need to invest in a big, expensive and hard to maintain server that runs the entire application by itself. A company can save a significant amount of money investing in a collection of smaller or virtual servers or even use “the cloud”. They are often easier to maintain and combined they can outperform a big server. This brings us to the efficiency aspect. The efficiency gain argument is strengthened by explaining the security-related principle that 1,000 people can exit a room quicker through 10 small exits than through 1 big exit. The perception gain lies in the ability to let other machines do resource-consuming processes so the originating machine can keep the user informed, or even let the user do other tasks while the deferred processes are running. An appropriate quote from Helgi, “Make our fish look like a shark”, was illustrated by a photo of a fish in a bowl with a shark fin strapped to its back.

Indeed, nature already seems to have solved many of our problems for us. Take a look at an ant colony. They are well organized and very efficient in solving problems they might encounter. They benefit from their strength in numbers, their ability to work together and the fact they have specialised types of ants for different tasks. Translated to a distributed application, the application as a whole represents the colony and the components represent ants, doing their specific task to keep the colony running.

Distributing your application involves the following characteristics: decoupling, elasticity, high availability and concurrency. Decoupling means splitting your application into functional pieces, like a database, a frontend, a cache, etc. Elasticity is that if the usage of your application is growing beyond initial expectations, more distributed components can be added to increase the capacity of your application. In order to make such dynamic changes, a certain level of monitoring is required. The initial design of your distributed application should account for this from the start, because it is very hard to implement an expansion strategy when your application is just about to reach its limits. Some monitoring tools are commercial products, some are open source.

Bringing the monitoring and the elastic behaviour of your application together creates a beautiful solution: an application that knows when to add/release extra components (servers) to keep things running smoothly - and actually does so!

There were several pitfalls and proposed solutions mentioned in the session:

• local sessions; solvable by storing sessions in a db or memcache
• local memory; solvable by using networked memcache
• local files, uploads, writing to /tmp; solvable by storing on S3 or networked filesystem, serving static files from CDNs.

Internal APIs between the components of your application creates a level of abstraction which makes it possible to switch components (servers) without the other components realising it.

Next, Helgi illustrated a number of tools by telling several real-life stories about using these tools to implement distributed solutions for specific problems. Tools like Gearman, CloudSplit, syslogd, internal APIs, CouchDB, supervisord, Map/Reduce technique, Hadoop, ZeroMQ and others are all key items in the toolbox for creating scalable systems. Each story was an insightful look into real-world problems and distributed solutions. Especially the combination of a distributed application, extensive monitoring and the ability to automatically adapt to certain events was an appealing concept to me. I wish I could recite all his anecdotes right here, but remembering all details from a 3-hour tutorial is nearly impossible. If you have the opportunity to see Helgi speak at a conference or even talk to him in person, don't hesitate to do so!

You can see Helgi's slides over on slideshare - worth a look for the points outlined above and the excellent fish/shark picture!

                          

On the morning of the conference, I rushed to get the Metro and was slightly confused by the sheer size of the RAI, which meant I didn't get a chance to get a coffee before the opening keynote. Luckily Aral Balkan bounded onto the stage with more infectious energy than any stimulating beverage could have provided. Aral is both a developer (check out his iOS Twitter client, Feathers) and a UX (user experience) consultant.

Having Aral doing the keynote was a brilliant move. UX is something we all have to think about and as a developer I love being exposed to design concepts; it improves how I think about the whole software development lifecycle. Although the lines between designers and developers are becoming blurred, we still have lots to learn from each other. Aral suggested that the age of features is dead, and that we are now in the age of user experience - that rather than features differentiating between products, it is how we feel when using them. Do they make you feel like a helpless child (e.g. baffling Windows error messages, or handles on a push door) or Superman (e.g. single swipe credit card entry to the Norwegian Metro). I now realise why, on the flight home, it felt awesome boarding a plane with with just a passport and a QR Code on my phone. Aral kicked off the conference in fine style and his performance foreshadowed what would be a great conference.

Having 4 tracks at the conference meant I had some difficult decisions to make: for the first talk of day I had to turn down Ian Barber talking about ZeroMQ (luckily I had seen that at PHP UK and I highly recommend seeing it if you get a chance) and Rowan Merewood talking about Test-Driven Development and instead opted for Paul Matthews talking about Solr). Apache Solr is an Apache top level project that builds upon the Lucene engine to provide advanced search capabilities. Paul has extensive experience with Solr and his talk was full of details. His nerves were apparent at the beginning, but by the end he was deftly handling all the questions the audience threw at him. He even wrote a blog post about this first speaking experience, which is a great read for aspiring conference speakers.

After that, I wanted to see Cal Evans (whose Voices of the Elephpant podcast I've been enjoying). He gave an interesting talk about Zend Framework from the Command Line. While using curl or wget from a Cron task to hit a URL in an existing app is all well and good, and indeed Worpress, Drupal and Magento all use that technique, there are better options available with Zend Framework.

Cal showed his approach using a CLI bootstrap file and CLI controller which can be called from the command line and provides all the components of Zend Framework. He showed a command line application that would send a text or call a phone from the command line using the Tropo API. This approach to CLI applications is a great way for us developers to realise the aphorism: 'a great engineer makes tools that help other people' - and by embracing the command line we can now make those tools and distribute them easily.

After a quick caffeine top-up it was onto to see Alistair Stead talk about automating your development environment. We are accustomed to using source control for our application code, but we can now do the same for the infrastructure we use, by using Chef. Chef uses Ruby scripts (yes, Alistair showcased Ruby code at a PHP conference and survived!) to abstract away the vagaries of diverse package management systems across different operating systems. Servers can be built repeatedly and consistently across many machines and even the Ruby code can be versioned to keep track of changes. Alistair also used Vagrant to automatically create a local virtual machine as his demo - one command with build and configure a LAMP server on your machine!

In the next session, I saw Evert Pot talking about REST where he expounded the virtue of using a proper REST interface but to not be too zealous about it. My inner geek enjoyed the recap of HTTP codes and their groupings, including everyone's favourite: HTTP 418.

After another quick caffeine break I went to see Kore Nordmann talk about Distributed Couch Apps. He gave a quick introduction to CouchDB's HTTP API and demonstrated creating a database and adding documents and then returning JSON objects from Couch, but the fun comes when you add CouchApp to the mix. CouchApp is a project built on top of CouchDB that uses CouchDB's server capabilities to deploy an entire web application. This talk was really interesting and certainly piqued my interest in Couch and got me thinking about how I can use it in one of my projects.

To round off the day I saw Rob Allen talk about Zend Framework 2. And there is lots of awesome stuff! ZF 1 has been around since 2006 which is an eon in Internet terms. The things that have been done with that single API are great, but we have now outgrown it and Zend Framework developers are being limited with the things they can do. Namespaces, better use of Interfaces, autoloading, revised plugin architechture, Exceptions, Service Locator with DI and improved community interaction are among the many things the are new or improved in ZF2. Rumour has it that ZF2 beta will be released in October with the stable version being released in December - this is still theoretical of course so don't hold Rob Allen or your humble author to that date!

The conference social was held at Club NL kindly sponsored by Ibuildings, Github and Sanoma Digital. There was quite a crowd and the free beer was much appreciated, however the venue itself was rather small and the music was loud, which made the 'social' aspect of the event slightly tricky! We walked back to our hotel with our heads buzzing with new ideas (and the free beer), happy in the knowledge that we could do it all over again the next day!

                          

One was the rate at which ideas were exchanged, both during the regular conference days and at the associated social events. Triggered by the talks they attended, people from many different nationalities were discussing a broad range of subjects, ranging from front-end technologies like HTML5, via the pitfalls of API design, to Extreme programming and its merits. Although this isn’t anything new for conferences like this, I felt that this year was extra dynamic. Many people I talked to were very enthusiastic about their co-attendees and their ideas.

Exchanging ideas is ultimately the goal of a conference like this. When everyone goes home inspired and with a head full of new ideas and insights, the conference was a success. This was clearly the case with DPC11. A prime example of a talk that inspired people was Aral Balkan’s keynote: The Art of User Experience. It was easily the most discussed talk of the conference. It was cool to watch all these PHP developers get excited about UX.

The other thing to stand out was the fact that many talks were not about PHP. That sounds a bit strange for a PHP conference, but to take a closer look at the subjects of the different talks let us do a little not-very-scientific analysis.

I started out with determining the ratio was of PHP vs. non-PHP talks. This was what I came up with:

• Talks about PHP or directly related technology: 16 (37%)
• Talks NOT about PHP: 18 (42%)
• 50/50 (mostly not PHP, but with PHP examples): 9 (21%)

As we can see, only 37% of all talks were about PHP-specific subjects, such as Zend Framework, Doctrine 2, PHP extensions, etc. All other talks were about more generic subjects to do with software engineering or web development, sometimes in a PHP context. What, if anything, does this tell us about the interests of PHP developers? To be able to draw any conclusions we need to have a closer look at the subjects of the talks. To that end, I tried to categorise the talks in a few broad subject categories *:

• Architecture: 11 (26%)
• Methodology: 6 (14%)
• Tooling: 5 (12%)
• Technical/Coding: 16 (37%)
• Front End: 2 (5%)
• Framework news: 3 (6%)

Disclaimer: I understand that my categorisation of the talks is rough and could be subject to discussion. But even if we would shuffle some talks around, I think the general picture stays the same.

It is immediately obvious that there were a lot of talks focusing on general software engineering subjects like architecture, methodology and tooling. Together they made up more than half of all talks. Of course there was still a lot of focus on the more technical talks with subjects ranging from profiling PHP to handling i18n and l10n with Zend Framework: a decent 37%. Another thing that is very noticeable is the scarcity of talks about front end technologies such as Javascript and HTML5 or about UX in general: only 5%.

How do these categories share out between the PHP and non-PHP talks then?

We can clearly see that most of the talks focusing on architecture, tooling and methodology are not PHP-specific. To me this means that the PHP community is becoming even more mature than it already is. We already moved into the enterprise market with the help of decent frameworks and by adopting concepts like continuous integration and continuous deployment. Many developers and companies have already made a choice for their preferred framework and can develop good quality software: no one is reinventing the wheel anymore.

Today we want to have efficient development teams and flexible architectures that can easily accommodate changes. This is reflected in the many talks about architectural subjects such as API design, Domain Driven Development, Modular Application Architecture, Test Driven Development, etc. The need for more efficient teams was evident in the subject of talks too: there were no fewer that four talks about agile development or team management.

For today’s PHP development teams, generic software engineering principles and technologies allied to PHP have become part of their architectures and daily work routine. It is only logical that we want to know more about them and learn about new ones. It is no surprise then, that we see schedules at PHP conferences which include a good proportion of talks that are not directly about PHP itself.

Having said so much about the diversity of topics, I still found that there was a subject that was conspicuously absent: development for mobile. This is a very hot subject right now and will remain so for the forseeable future. There were talks about API development, which is crucial for mobile development. But APIs are only one part of publishing to mobile: we also need to talk about the client technology. Even without talks about Objective C or Java, I would have very much liked to see some talks about how to go mobile with technology that we already use - such as PHP, HTML5, CSS3 and Javascript.

Apart from that small nitpick, I think it was a great conference. I enjoyed myself immensely, met a lot of people and learned a lot. I would like to thank all attendees, speakers, organisers and of course my Ibuildings colleagues for their contributions. Hope to see you all again next year!

                          

Explaining The Shipping Architecture

Before making our own module, we’ll look at how Magento’s existing shipping rate functionality operates. If you are already familiar with this, then you should skip to the next section.

For this walkthrough we’ll use the “Flatrate” shipping method which is available by default with Magento. This method requires two files (excluding inherited classes and so on), these are:

• app/code/core/Mage/Shipping/Model/Carrier/Flatrate.php
• app/code/core/Mage/Shipping/etc/config.xml

Open Flatrate.php and take a look - there are four elements of the class which are essential to the operation of this rate.

app/code/core/Mage/Shipping/Model/Carrier/Flatrate.php

protected $_code = 'flatrate';
protected $_isFixed = true;
 
public function collectRates() {}
public function getAllowedMethods() {}

The first important element is the $_code property. This is a code which must be unique to your shipping method. It’s important to note this code is specified in other places, so you need to be consistent with its naming (more on this later). The next property, $_isFixed, is telling Magento that this shipping method is a fixed, one time fee - rather than a recurring payment, which is the alternative option here.

The second file is config.xml; this file is for all Magento shipping methods and as such, it is quite large. However, we are only interested in one part of it:

app/code/core/Mage/Shipping/etc/config.xml

<carriers>
    <flatrate>
        <active>1</active>
        <sallowspecific>0</sallowspecific>
        <model>shipping/carrier_flatrate</model>
        <name>Fixed</name>
        <price>5.00</price>
        <title>Flat Rate</title>
        <type>I</type>
        <specificerrmsg>This shipping method is currently unavailable...(etc)</specificerrmsg>
        <handling_type>F</handling_type>
    </flatrate>
</carriers>

Notice how the node is called <flatrate> to match the $_code property in the Flatrate.php class we saw earlier. Most of the nodes above are easy to understand, but some will benefit from a little more explanation:

The <model> node in config.xml, as shown above, tells Magento which shipping class to use; in our example, that is shipping/carrier_flatrate. Magento converts shipping/carrier_flatrate to Mage_Shipping_Model_Carrier_Flatrate (found in app/code/core/Mage/Shipping/Model/Carrier/Flatrate.php). The class within Magento responsible for loading the correct rate is Mage_Shipping_Model_Shipping. It is a good idea to take a look at this class and familiarise yourself with how Magento handles this.

We can also take a deeper look at the flatrate classfile. This class extends Mage_Shipping_Model_Carrier_Abstract and implements Mage_Shipping_Model_Carrier_Interface. In fact since all shipping methods must do the same, we can work out which methods require implementation, and which are already there. In general we will be interested in implementing two methods:

• collectRates()
• getAllowedMethods()

All other implementation is provided in Mage_Shipping_Model_Carrier_Abstract, so these two methods are all we need to create our own shipping model.

Creating Your Own Rate

This example shows how to create a simple shipping rate, which can provide the basis of a more complicated rate should you need to adapt this for your own purposes. The first step is to make our module skeleton by creating a directory structure along these lines:

app/code/local/Foobar/
app/code/local/Foobar/Shipping/
app/code/local/Foobar/Shipping/etc/
app/code/local/Foobar/Shipping/Model/

Then we need to add a module activation file to app/etc/modules/Foobar_Shipping.xml with the following contents:

app/etc/modules/Foobar_Shipping.xml

<?xml version="1.0"?>
<config>
    <modules>
        <Foobar_Shipping>
            <active>true</active>
            <codePool>local</codePool>
            <depends>
                <Mage_Shipping/>
            </depends>
        </Foobar_Shipping>
    </modules>
</config>

Next we make the config file; here’s the one I used when creating this example:

app/code/local/Foobar/Shipping/etc/config.xml

<?xml version="1.0" ?>
<config>
    <modules>
        <Foobar_Shipping>
            <version>0.1.0</version>
        </Foobar_Shipping>
    </modules>
    <global>
        <models>
            <foobar_shipping>
                <class>Foobar_Shipping_Model</class>
            </foobar_shipping>
        </models>
    </global>
    <default>
        <carriers>
            <foobar_customrate>
                <active>1</active>
                <model>foobar_shipping/carrier_customrate</model>
                <title>Foobar Shipping</title>
                <name>Default Rate</name>
            </foobar_customrate>
        </carriers>
    </default>
</config>

Finally we add our custom shipping class.

app/code/local/Foobar/Shipping/Model/Carrier/Customrate.php

<?php
 
class Foobar_Shipping_Model_Carrier_Customrate
    extends Mage_Shipping_Model_Carrier_Abstract
    implements Mage_Shipping_Model_Carrier_Interface
{
    protected $_code = 'foobar_customrate';
    protected $_isFixed = true;
 
    public function collectRates(Mage_Shipping_Model_Rate_Request $request)
    {
 
        if (!$this->getConfigFlag('active')) {
            return false;
        }
 
        $result = Mage::getModel('shipping/rate_result');
 
        $method = Mage::getModel('shipping/rate_result_method');
        $method->setCarrier('foobar_customrate');
        $method->setCarrierTitle($this->getConfigData('title'));
        $method->setMethod('foobar_customrate');
        $method->setMethodTitle($this->getConfigData('name'));
        $method->setPrice(5);
        $method->setCost(2);
 
        $result->append($method);
 
        return $result;
    }
 
    public function getAllowedMethods()
    {
        return array('foobar_customrate' => $this->getConfigData('name'));
    }
}

After clearing your cache, go and ahead and add a product to your cart and go to checkout. You should see our shipping method sitting there with a charge (of 5 units of whatever currency your Magento is set up to use). Congratulations - you have a basic shipping module available for use!

Behind the Scenes

When we hit the checkout, Magento uses the collectRates() method in our class; via this method you can offer shipping rates (or not) by storing an object in $result, which is Mage_Shipping_Model_Rate_Result. Basically, you add instances of Mage_Shipping_Model_Rate_Result_Method ($method in our example) to this object via the append() method. The rate result object holds all the values such as carrier and method name, as well as the all-important price and cost. In this way it becomes easy to offer multiple rates via the collectRates() method, simply by creating more rate results and calling append() for each one, in this way:

<?php
 
$result = Mage::getModel('shipping/rate_result');
 
$method = Mage::getModel('shipping/rate_result_method');
$method->setCarrier('foobar_customrate');
$method->setCarrierTitle($this->getConfigData('title'));
$method->setMethod('foobar_customrate_one');
$method->setMethodTitle('Rate 1');
$method->setPrice(5);
$method->setCost(2);
 
$result->append($method);
 
$method = Mage::getModel('shipping/rate_result_method');
$method->setCarrier('foobar_customrate');
$method->setCarrierTitle($this->getConfigData('title'));
$method->setMethod('foobar_customrate_two');
$method->setMethodTitle('Rate 2');
$method->setPrice(5);
$method->setCost(2);
 
$result->append($method);

After using the code above, you will see two shipping methods available for use. Methods are grouped by carrier, and the Carrier Title and Method Title are displayed on the frontend. If your shipping method uses multiple rates then it makes little sense to use the config to specify the names attribute, which is why they are hardcoded here. In this case you are free to remove the <name> node from your config.xml, as it is not used anywhere else.

Shipping Methods in Magento

This post outlined the absolute essentials for creating a simple custom shipping method. You can now go ahead and use or adapt this for use in your own applications. As with all aspects of Magento, great flexibility is available, once you know how to work with it, and hopefully this post will be useful for anyone dealing with shipping rates.

                          

If you would be able to attend and would like the ticket, leave a comment on the post telling us why you want to be there, and we'll pick a winner from the commenters! Be quick though, the event is next week so we'll be closing this competition very soon ...

Update: And the winner is… Lee Davis!
Congratulations Lee, looks like you’re going to eZ Conference & Awards!

                          

Tournament key rules

• If a player attempts to make any illegal move, they will automatically lose the match. Illegal moves are trying to insert a disc into a column that's full, or trying to insert a disc into a column that doesn't exist.
• To keep things fair for everybody, we created 3 categories based on your PHP experience (0-2 years experience, 2-4 years experience, 4+ years experience).
• Points were awarded in the following way:
  • 3 points for a win
  • 1 point for a tie
  • no points for a lose

Let the Battle Commence

Four in a Line as game has been mathematically solved and the advantage lies with the player taking the first turn. To level the playing field, we allowed each player to fight against all the others; in this way, any player had the chance to begin with the first move advantage playing against all the other opponents at least once, sharing the elements of luck and making it easier to spot skill. Each game was played on the official 7 x 6 grid on a basis of three rounds per game. At the end of each qualification session only the players with the highest score moved further in the tournament.

Competition Entries

As usual we had 3 categories; Junior developers, Medium developers and Senior developers. In contrast to our previous challenges however, every single submission was successful, with every entry able to play the game within the rules successfully.

Winners

The competition is designed to be fun for the participants, but it is also good fun for us too and we have to say that the whole challenge has been very exciting and interesting. We will comment on the trends we saw but first: the winners!

Junior category

In the Junior category we had only two submissions, their games played very fast (all less than 1 second) due to the simplicity of the algorithm implemented; despite this we have to say that the quality of the code was pretty good in this category.

Category Winner Junior: Xavier Van Herpe

Medium category

We saw 4 submissions for this intermediate section and in general, the execution time increased. There were plenty of fast games but the average time was about 3 minutes and 30 seconds. Code quality is increased and we started to see some advanced gaming logic and strategy. Players anticipated the play and picked moves with consideration for what their following move would be.

A special mention goes to Tobias Rojahn because with a relatively short implementation in terms of lines of code, his gamer played very well.

Category Winner Medium: Piotr Mlocek

Senior category

This category for more experienced developers delivered a huge range of submissions, from a very interesting tiny implementation from Klaus Jorgensen, less than hundred lines, to the most complex and much larger proposal by Tomas Creemers. The longest game took exactly 04h 56m 09s on a 2.53Ghz Intel Core 2 Duo. Again we'd like to give a special mention in this category, this time to Tjado Maecke: his virtual player was the only one able to challenge our winner, scoring one win and a couple of draws.

Category Winner Senior: Tomas Creemers

Prizes

Amongst all the winners, we raffled three prizes: 2 tickets to the Dutch PHP Conference and an iPad. The prizes go as follows:

DPC tickets: Xavier Van Herpe and Piotr Mlocek
iPad: Tomas Creemers

Congratulations to all the winners!

Observations

In this challenge, we didn’t impose any strict restrictions regarding performance, code standards or time limits, the only rule was to play and win. It was interesting to us to see how various programming practices varied across the submissions, and we think that it's important to remark on some basic but very important general notions as we saw it.

Coding standards

Whether you are new to PHP programming or a seasoned veteran you can benefit from following a set of coding standards. Such standards haven't always been a key area, but nowadays PHP reaches so many major projects and enterprise organisations that we'd expect to see these consistent standards everywhere the language is used. Between the 14 developers in this challenge, we saw four general different coding styles plus several personal touches. Personal touch is acceptable in some settings, but a developer must remember that the code is going to be read by someone else and the reader should be comfortable with it.

We have a previous article about PHP Code Sniffer so check that out if you're looking for a tool to help you with standards. We also advise that one of the existing standards such as Zend or PEAR are better than inventing your own standard for code.

Performance

As developers, we often need to find a compromise between complexity and precision versus speed and approximation. We have seen a very good virtual player win and play ten times faster than others, and we also saw games that ran for many hours. As an example, when we ran some contests in simulation mode to see how the AI were working, we saw this scenario:

. X X X . . O


The (X) player was the one supposed to make the next move and the AI took more than 10 minutes to decide what that move should be. We understand the algorithm has been implemented to be good and successful but in a real scenarios the KISS approach would have helped a lot!

Conclusions

For us as organisers, this has been another fun challenge and we look forward to the next (watch this space!) We offer our warm congratulations to all our participants for such a high standard of submission, and especially to our winners who fought off some stiff competition to emerge victorious. Thanks to all of you and we hope you had as much fun as we did!

                          

If you've had an idea for writing a blog post or article, but you're not sure where to start, this talk is for you! Maybe you've had difficulty effectively documenting your code, or communicating your ideas to non-techies. This talk will help you, too! In this fun and informative session, we'll discuss the basics of writing and clear communication through the written word. We'll also talk about strategies for keeping your writing interesting and informative at the same time. Finally, we'll discuss resources for improving your writing skills in the future.

This session definitely loses something if you can't see Elizabeth's slides, so download them and follow along