Two of the most common methods to stay up-to-date with latest stuff is to use some RSS/Atom Aggregator or subscription via emails at various sites. These work fine but I was personally overwhelmed by the amount of new updates and posts I used to get, it was kind of hard to keep the track of it all with that many subscriptions from various sources on different technologies. I could have minimized the subscriptions but that wouldn't save the actual purpose.

Therefore being a developer, often times, you come up with your own solution which fits your needs. I wanted just a simple and focused app on just one technology eg PHP that would give me updates from various sources in one central place without bloating me away with too many or stale posts. Since idea was simple, I didn't want to spend too much time on Android so I took the route of using JavaScript to create this app. It turned out there are quite some ways to create Native apps today using one technology that can run across devices and platforms. I found NativeScript quick and easy to get started with although there are other solutions too to make native apps such as ReactNative, Xamarin, Flutter, etc.

Over the weekend, I went on to creating this app called PHPNews and I believe end result is exactly what I wanted as it serves the purpose, here is screenshot:

It collects information from various sources including official blogs of PHP frameworks such as Laravel, Symfony, Zend Framework and CMSs like WordPress and last but not the least our old friend planet-php.net.

Definitely give it a try and also share any suggestions or improvements.

View PHPNews on Android PlayStore

Here is the pattern used by glob function to detect and delete all junk files:

protected $patterns = [
    '.git',
    '.github',
    'test',
    'tests',
    'travis',
    'demo',
    'demos',
    'license',
    'changelog*',
    'contributing*',
    'upgrading*',
    'upgrade*',
    '.idea',
    '.vagrant',
    'readme*',
    '_ide_helper.php',
    '{,.}*.yml',
    '*.yaml',
    '*.md',
    '*.xml',
    '*.log',
    '*.txt',
    '*.dist',
    '*.pdf',
    '*.xls',
    '*.doc',
    '*.docx',
    '*.png',
    '*.gif',
    '*.jpg',
    '*.bmp',
    '*.jpeg',
    '*.ico',
    '.php_cs*',
    '.scrutinizer',
    '.gitignore',
    '.gitattributes',
    '.editorconfig',
    'dockerfile',
    'composer.json',
    'composer.lock',
];

The command itself can be seen here.

To automatically cleanup junk files/folders when installing or updating composer packages in Laravel, @php artisan vendor:cleanup should be added under the post-autoload-dump section in composer.json file. Or we can also trigger it manually anytime by typing php artisan vendor:cleanup --o where --o is optional argument to display verbose output.

If you actually want to be able to use this idea of cleanup of useless files in any PHP project (Laravel or not), you might want to create a composer plugin instead and install it globally that can then work across PHP projects and cleanup useless files from the vendor folder.

If you witness any issue or something missing in the pattern list shown above, please leave your suggestion/improvements in comments. Thanks

Features

• Send and receive messages
• Read Receipts
• Switch between users to chat with
• Popup notifications for new chat messages
• Privacy settings for popup notifications
• One-time authentication, no need to scan QR code again and again
• Windowless/headless (hidden) mode
• Colorful chat messages

Screenshot

Head over to Whatspup repository and start using it :)

Screenshot

Checkout Laravel QueryDumper

I sat down over the weekend and came up with my own solution Floyer (shortened from FTPDeployer). It works with both git and svn and is quit fast able to upload hundreds of files in few seconds. Other than FTP, it also supports SFTP.

How does it work

• It stores revision/commit hash on the server in a file when deployment is started.
• On next deployment, it compares local revision with remote one thereby able to deploy only the files changed between these two revisions.
• Once it knows what files to upload, it creates zip archive of these files to be deployed on the server.
• Rather than uploading each file individually (which is very slow process), it creates and uploads zip archive file to server where there is corresponding extract zip PHP script which extracts these files very fast. This script is also created and uploaded by Floyer.
• After deployment is finished, zip archive and extract script is deleted automatically.

Deploying by uploading and extracting archive file not only makes deployment fast but also we don't have to worry about some permission issues or creating new directories and so on because extract script runs from server itself thereby avoiding these issues.

Screenshot

Checkout Floyer at Github

First I came across ratchet library, it worked great but problem emerged when setting it up on secure connection (https) on my host (siteground), tried apache proxy module and everything else told on the internet but to no avail (it seems siteground has problem with ratchet on https) so in the end I had to drop ratchet.

Then I thought of using socket.io with Node+PHP and with my research I came across elephant.io library (though it isn't updated recently) and this one worked wonderfully well both on non-secure and secure protocols allowing us to send and receive messages from PHP with node-based server.

Here are the steps that I followed to get my notification system working.

Install elephant.io

For your PHP application, install elephant.io via composer:

composer require wisembly/elephant.io

Install Node Dependencies

Create a directory in your project root and under it create a file named package.json with these contents:

{
    "name": "elephantIO_example_emitter",
    "version": "3.0.0",
    "main": "server.js",

    "scripts": {
        "start": "supervisor --debug server.js"
    },

    "dependencies": {
        "socket.io": "~1",
        "winston": "*"
    }
}

On newly created directory run command npm install --save. This will install socket.io and logger library.

In same newly created directory, create a file server.js with these contents:

var server     = require('http').createServer(),
    io         = require('socket.io')(server),
    logger     = require('winston'),
    port       = 1337;

// Logger config
logger.remove(logger.transports.Console);
logger.add(logger.transports.Console, { colorize: true, timestamp: true });
logger.info('SocketIO > listening on port ' + port);

io.on('connection', function (socket){
    var nb = 0;

    logger.info('SocketIO > Connected socket ' + socket.id);

    socket.on('broadcast', function (message) {
        ++nb;
        logger.info('ElephantIO broadcast > ' + JSON.stringify(message));

        // send to all connected clients
        io.sockets.emit("broadcast", message);
    });

    socket.on('disconnect', function () {
        logger.info('SocketIO : Received ' + nb + ' messages');
        logger.info('SocketIO > Disconnected socket ' + socket.id);
    });
});

server.listen(port);

Run server.js file through node by typing node server.js, you should see message that server has started on specified port.

Client Side

Put following javascript code in your application's page/footer:

<script src='//cdnjs.cloudflare.com/ajax/libs/socket.io/1.7.4/socket.io.min.js'></script>

<script>
var socket = io.connect('//127.0.0.1:1337');

socket.on('connect', function () {
    console.log('connected');

    socket.on('broadcast', function (data) {
        //console.log(data);
        //socket.emit("broadcast", data);
        alert(data.text);
    });

    socket.on('disconnect', function () {
        console.log('disconnected');
    });
});
</script>

Sending Notification from PHP

Here is how you can send a message to all connected clients:

require __DIR__ . '/vendor/autoload.php';

use ElephantIO\Client;
use ElephantIO\Engine\SocketIO\Version1X;

$client = new Client(new Version1X('//127.0.0.1:1337'));

$client->initialize();
// send message to connected clients
$client->emit('broadcast', ['type' => 'notification', 'text' => 'Hello There!']);
$client->close();

and that's all there is to it.

Installing and Running Node on Production Site

I was on CentOSv6 and I installed node by following this guide. Then I created simple php file that will be run by cron so that node server is automatically started/restarted if it is not running:

$nodePath = 'your node binary path here';
$filePath = 'your server.js file path';
shell_exec($nodePath . ' ' . $filePath);

and then specify that file in cron to run at your specified time intervals.

Important Notes

• I was having bit of issue getting node path from PHP script where I initially installed it so I copied the nodejs folder to my public_html folder (app's root).
• On production site, I had to type actual server IP rather than 127.0.0.1 on client side code eg instead of var socket = io.connect('//127.0.0.1:1337');, it has to be var socket = io.connect('//SERVER_IP_HERE:1337');
• If you are having issue getting it to work on https, check out issues section to fix it.
• Check out examples folder of elephant.io to know how to send or receive messages both from PHP as well as Javascript.

Features

• Other than basic log such as IP, Browser and OS, it can also log Location information.
• Allows to log both unique and non-unique visits based on IP.
• Allows to cache the visits based on IP.
• Allows to log authenticated user info.
• Provides log viewer page out of box.

Screenshots

Visit Package Repository to know more about it and installation.

• Dependency Injection (My previous post on DI)
• Dependency Injection Container (DIC)
• Services

Even though these terms seems scary at first especially to new-comers but are really easy to understand and help write quality code that is easy to understand and extend. We will take a ^legacy code^ and convert it into object-oriented one by using these principles.

Suppose we have simple application that sends newsletter email to all its subscribers, here is the legacy code:

// file: index.php or could also be considered as Controller file in MVC paradigm

require __DIR__ . 'vendor/autoload.php';

use Demo\Mailer\SmtpMailer;

$dsn = 'sqlite:' . __DIR__ . 'database.sqlite';
$pdo = new PDO($dsn);

$mailer = new SmtpMailer('smtp.example.com', 'user', 'password', '465');

$sql = 'SELECT * from subscribers';

foreach ($pdo->query($sql) as $row) {
    $mailer->sendMessage(
        $row['email'],
        'This is the email body',
        $row['name'],
        'info@example.com'
    );
}

Right now above code smells and has these problems:

• Logic is mixed up, SQL queries, sending emails database configuration is all in one file

To fix this, first instinct is to convert it into class:

class SubscriberMailer
{
    public function sendEmails()
    {
        $dsn = 'sqlite:' . __DIR__ . 'database.sqlite';
        $pdo = new PDO($dsn);

        $mailer = new SmtpMailer('smtp.example.com', 'user', 'password', '465');

        $sql = 'SELECT * from subscribers';

        foreach ($pdo->query($sql) as $row) {
            $mailer->sendMessage(
                $row['email'],
                'This is the email body',
                $row['name'],
                'info@example.com'
            );
        }
    }
}

This looks good to eye but it has more problems:

• Logic is still mixed up, SQL queries, sending emails database configuration is all in one file
• It has hard-coded dependencies (tight-coupling) on PDO and Mailer class, what if we wanted to change Mailer class ?
• It is hard to unit-test because of tight coupling

Let's try to fix these problems. We can see that this class has dependency on PDO so instead of hard-coding it inside SubscriberMailer class, we can ^pass^ it via its constructor which now makes the class:

class SubscriberMailer
{
    protected $pdo = null;

    public function __construct($pdo)
    {
        $this->pdo = $pdo;
    }

    public function sendEmails()
    {
        $mailer = new SmtpMailer('smtp.example.com', 'user', 'password', '465');

        $sql = 'SELECT * from subscribers';

        foreach ($this->pdo->query($sql) as $row) {
            $mailer->sendMessage(
                $row['email'],
                'This is the email body',
                $row['name'],
                'info@example.com'
            );
        }
    }
}

This is a bit better, the class doesn't care where PDO objects comes from, it just needs one to operate and you can't instantiate the class without providing one so it makes its intention clear. So this is what is called Dependency Injection, no need to fear even though the term sounded scary initially (read my previous article on more ways of injecting dependencies). Here is how we use above class at this point of the time:

require __DIR__ . 'vendor/autoload.php';

use Demo\Mailer\SmtpMailer;
use Demo\Mailer\SubscriberMailer;

$dsn = 'sqlite:' . __DIR__ . 'database.sqlite';
$pdo = new PDO($dsn);

$subscriberMailer = new SubscriberMailer($pdo);
$subscriberMailer->sendEmails();

This is starting to look better compared to first snippet of code. However, we still have a problem in that we have hard-coded smtp config into our class, what if we wanted to change the smtp config without touching the class ? Or what if we had different setup of smtp config for development and production ? Remember a class should be a black-box which simply does its job without editing it again and again, you can only extend it not edit it. So this reasoning hints us that like pdo, we should also pass smtp config via class's constructor and move it from the class itself.

class SubscriberMailer
{
    protected $pdo = null;
    protected $smtpConfig = [];

    public function __construct($pdo, array $smtpConfig)
    {
        $this->pdo = $pdo;
        $this->smtpConfig = $smtpConfig;
    }

    public function sendEmails()
    {
        $mailer = new SmtpMailer(
            $this->smtpConfig['host'],
            $this->smtpConfig['user'],
            $this->smtpConfig['password'],
            $this->smtpConfig['port']
        );

        $sql = 'SELECT * from subscribers';

        foreach ($this->pdo->query($sql) as $row) {
            $mailer->sendMessage(
                $row['email'],
                'This is the email body',
                $row['name'],
                'info@example.com'
            );
        }
    }
}

Usage:

require __DIR__ . 'vendor/autoload.php';

use Demo\Mailer\SmtpMailer;
use Demo\Mailer\SubscriberMailer;

$dsn = 'sqlite:' . __DIR__ . 'database.sqlite';
$pdo = new PDO($dsn);

$subscriberMailer = new SubscriberMailer($pdo, [
   'host' => 'smtp.example.com',
   'user' => 'user',
   'password' => 'password',
   'port' => '465',
]);

$subscriberMailer->sendEmails();

This is better, we can now readily change smtp config in one place and we don't have to touch our class. It still has these problems though:

• It is tightly coupled to SMTP mailer, what if we wanted to change mailer from smtp to another one like sendmail ?
• SQL is still written in our class, logic is mixed up, our mail class shouldn't know about users or interact with database, it just needs to send emails !

Hint: The new keyword is considered code-smell, whenever you encounter it, it means it is something you should pass via dependency injection.

So by now we know that to remove hard-coded dependency or tight-coupling, we should pass it instead via dependency injection. So instead of passing mailer config, we should pass mailer object:

class SubscriberMailer
{
    protected $pdo = null;
    protected $mailer = null;

    public function __construct(\PDO $pdo, SmtpMailer $mailer)
    {
        $this->pdo = $pdo;
        $this->mailer = $mailer;
    }

    public function sendEmails()
    {
        $sql = 'SELECT * from subscribers';

        foreach ($this->pdo->query($sql) as $row) {
            $this->mailer->sendMessage(
                $row['email'],
                'This is the email body',
                $row['name'],
                'info@example.com'
            );
        }
    }
}

Usage:

require __DIR__ . 'vendor/autoload.php';

use Demo\Mailer\SmtpMailer;
use Demo\Mailer\SubscriberMailer;

$dsn = 'sqlite:' . __DIR__ . 'database.sqlite';
$pdo = new PDO($dsn);

$mailer = new SmtpMailer('smtp.example.com', 'user', 'password', '465');

$subscriberMailer = new SubscriberMailer($pdo, $mailer);       
$subscriberMailer->sendEmails();

This is better, we removed hard-coded dependency to smtp mailer and notice that we have also type-hinted the PDO and SmtpMailer in the constructor of our class, this is extremely helpful because:

• Our class makes clear intention that it needs a PDO and SmtpMailer to work properly
• If somebody passes something other than these two dependencies, they would get clear error message
• Type-hinting makes our code self-documenting
• It makes IDE auto-completion

Right now our mailer class knows it needs an instance of SmtpMailer to work and it should have a sendMessage method. Remember, we refactored our code in hope that we might use some other type of mailer like sendmail but problem is that it might not necessarily have the sendMessage method which means we cannot use it. So how do we solve this problem to be able to use some other type of mailer implementation ? Well the answer is to use an interface/contract and use that instead:

// app/Demo/Contracts/MailerInterface.php
interface MailerInterface
{
   public function sendMessage($email, $body, $subject, $from);
}

// app/Demo/Mailer/SmtpMailer.php
use Demo\Contracts\MailerInterface;

class SmtpMailer implements MailerInterface
{
    public function sendMessage($email, $body, $subject, $from) {
        // code to send email
    }
}

// app/Demo/Mailer/SubscriberMailer.php    
class SubscriberMailer
{
    protected $pdo = null;
    protected $mailer = null;

    public function __construct(\PDO $pdo, MailerInterface $mailer)
    {
        $this->pdo = $pdo;
        $this->mailer = $mailer;
    }

    public function sendEmails()
    {
        $sql = 'SELECT * from subscribers';

        foreach ($this->pdo->query($sql) as $row) {
            $this->mailer->sendMessage(
                $row['email'],
                'This is the email body',
                $row['name'],
                'info@example.com'
            );
        }
    }
}

Just like every step that we are performing, this step also has nice advantages:

• Our SubscriberMailer class is now greatly expandable since it now accepts ANY object that implements MailerInterface that has sendMessage method
• It documents our code a bit more, it is clear now how an object should be constructed that implements the MailerInterface

All well and good so far. We now see that in our class has SQL to get users. Again it should not care about talking to database, it just needs users' emails to send emails to. To fix this, we need use the Repository Pattern which is essentially a class talking to database to manipulate specific entity, in this case users. So we can pass UserRepository as dependency that has a method to get all users:

// app/Demo/Mailer/SubscriberMailer.php
use Demo\Contracts\MailerInterface;
use Demo\Repositories\UserRepository;

class SubscriberMailer
{
    protected $mailer = null;
    protected $userRepository = null;

    public function __construct(MailerInterface $mailer, UserRepository $userRepository)
    {
        $this->mailer = $mailer;
        $this->userRepository = $userRepository;
    }

    public function sendEmails()
    {
        $users = $this->userRepository->getAll();

        foreach ($users as $user) {
            $this->mailer->sendMessage(
                $user->email,
                'This is the email body',
                $user->name,
                'info@example.com'
            );
        }
    }
}

Usage:

require __DIR__ . 'vendor/autoload.php';

use Demo\Mailer\SmtpMailer;
use Demo\Mailer\SubscriberMailer;
use Demo\Repositories\UserRepository;

$mailer = new SmtpMailer('smtp.example.com', 'user', 'password', '465');

$subscriberMailer = new SubscriberMailer($mailer, new UserRepository);    
$subscriberMailer->sendEmails();

Awesome! our SubscriberMailer class now does not have any mixed-up logic, it is complete black-box whose task is to send emails to provided users. It doesn't need to care about how you pass MailerInterface or UserRepository, it just needs them to operate. It has only one task of sending emails. Not to mention that our class is also easy to be unit-tested. Notice also that we removed PDO as dependency since it is now job of UserRepository to give us the users.

We can now call our class a Service that performs one and only one task without any coupling. If you have heard about Service-Oriented Architecture, this is what it is, a collection of service classes with one and only one responsibility each without any hard-coded dependencies.

At this point of the time, we are all good with our class but one of the downsides of Dependency Injection is that all the complexity of creating and configuring objects is your job. Now this isn't that bad since it happens at one place and gives you the control but it is something which we can still improve.

To do this, we need to leverage what is called Dependency Injection Container (DIC). The job of DIC is to create and configure objects for us. There are many DIC out there for PHP but let's see our modified code using famous Pimple container, here we wrap the dependencies or services into Pimple container. I am not going into details of how to use it, you should refer to its documentation.

// file: container.php

use Demo\Mailer\SmtpMailer;
use Demo\Repositories\UserRepository;
use Pimple\Container;
use Demo\Mailer\SubscriberMailer;

$container = new Pimple();

// container can also hold configs - ideally should be put in separate file...
$container['smtp_config'] = [
   'host' => 'smtp.example.com',
   'user' => 'user',
   'pass' => 'password',
   'port' => '465',
];

$container['mailer'] = $container->share(function(Pimple $container){
   return new SmtpMailer(
      $container['smtp_config']['host'],
      $container['smtp_config']['user'],
      $container['smtp_config']['pass'],
      $container['smtp_config']['port']
   );
});

$container['userRepository'] = $container->share(function(){
   return new UserRepository();
});

$container['subscriberMailer'] = $container->share(function(Pimple $container){
   return new SubscriberMailer($container['mailer'], $container['userRepository']);
});

// file: index.php

require __DIR__ . 'vendor/autoload.php';
require __DIR__ . 'container.php';

$subscriberMailer = $container['subscriberMailer'];
$subscriberMailer->sendEmails();

Notice how clear and concise our index.php code is now compared to initial version.

Using the DIC provides us with these advantages:

• Wrapping our object creation in container's anonymous function makes object creation lazy which means object isn't created only until needed and if we never reference our SubscriberMailer class, those objects are never created at all saving us memory !
• Using the container's share method means no matter how many times we need, it will always give us same original object instance. If we need to send many emails, we don't need many instances. This also makes code a bit more faster.
• All the logic of which objects depend on other objects is abstracted away into container itself, we don't need to worry how they are created or what their dependencies are, we just use our services straight away out of container.
• If we ever need to change config or something, we only edit it at one place, nobody needs to know about this change.

In conclusion, no matter which framework you use, these principles can be applied to make code which is easy to understand, extend and test.

If you have SSH access to server, we can leverage built-in MySQL commands mysqldump and mysql respectively to backup and restore big database really fast.

To Backup Database:

mysqldump -uDB_USER_HERE -pDB_PASSWORD_HERE DATABASE_NAME_HERE > backup.sql

To Restore Database:

mysql -uDB_USER_HERE -pDB_PASSWORD_HERE DATABASE_NAME_HERE < backup.sql

Note: If you don't have SSH access, you can use tools like MySQLDumper which does fairly good job but not as fast as mysqldump and mysql commands of course.

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:1

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.

Pretty formal definition hun ? let's understand through example actually.

Imagine we have rudimentary MySQL wrapper class:

class Mysql
{
    protected $db = null;

    public function connect($dsn, $user = '', $pass = '')
    {
        $this->db = new PDO($dsn, $user, $pass);
    }

    public function query($query)
    {
        return $this->db->query($query);
    }
}

Pretty common and valid code in old days we used to be proud while writing such class. There are couple of problems associated with it though:

• The class Mysql has implicit dependency (tight-coupling) on the PDO class. All dependencies should always be explicit not implicit.
• It is hard to unit-test due to implicit dependency

Let's use above class:

class User
{
    private $database = null;

    public function __construct()
    {
        $this->database = new Mysql();
        $this->database->connect('mysql:host=localhost;dbname=test', 'root', '');
    }

    public function getUsers()
    {
        $users = $this->database->query('SELECT * FROM users ORDER BY id DESC');
        print_r($users);
    }
}

$user = new User();
$user->getUsers();

Again pretty common piece of code but again this one has even more problems:

• The class User has implicit dependency (tight-coupling) on the Mysql class. All dependencies should always be explicit not implicit.
• It is hard to unit-test due to implicit dependency
• If we wanted to change database credentials, we need to edit the User class which is not good; every class should be completely modular or black box. If we need to operate further on it, we should actually use its public properties and methods instead of editing it again and again.
• Let's assume right now class is using MySQL as database. What if we wanted to use some other type of database ? You will have to modify class.
• The User class does not necessarily need to know about database connection, it should be confined to its own functionality only. So writing database connection code in User class doesn't make it modular. This defeats the Single responsibility principle.

You might wonder above code has problems but these days we write code based on MVC design pattern and follow best practices and write modern code but I am sure below code is pretty common even today using any framework you use:

class UserController extends Controller
{
    public function actionListAllUsers()
    {          
       // fetch all users from database
        $users = User::model()->findAll();

       // show them on screen
        print_r($users);          
    }
}

If you analyze this has same problems again in that class UserController is tightly coupled (implicit dependency) with User model class which also makes it hard to unit-test.

This means:

Coupled Code is Evil BIG DOT

So what's the solution ?

The solution is Dependency Injection (see my previous post Dependency Injection in PHP). The idea behind Dependency Injection is that instead of writing implicit dependencies, we should pass/provide those via constructor or setter method or even interface.

Let's refactor User class code and pass our dependency via constructor instead of hard-coding it inside User class method:

class User
{
    private $database = null;

    public function __construct(Mysql $database)
    {
        $this->database = $database;
    }

    public function getUsers()
    {
        $users = $this->database->query('SELECT * FROM users ORDER BY id DESC');
        print_r($users);
    }
}

$database = new Mysql();
$database->connect('mysql:host=localhost;dbname=test', 'root', '');
$user = new User($database);
$user->getUsers();

This is much better! We no more have implicit dependency on Mysql class which also makes our User class easier to unit-test. The class makes clear intention that it needs some sort of Mysql class. It also doesn't know (or care) where Mysql will come form, it just needs one to operate. The User class is now completely modular and follows single responsibility principle (that of manipulating users).

In the similar way, we can also improve our modern code:

class UserController extends Controller
{
    protected $user;

    public function __construct(User $user)
    {
        $this->user = $user;
    }

    public function actionListAllUsers()
    {          
       // fetch all users from database
        $users = $this->user->findAll();

       // show them on screen
        print_r($users);          
    }
}

Here again we pass dependency (User class) of UserController via its constructor making it much better. So all good ? Not really...

We still have a problem

One problem with User class which still persists is that it is tied to specific type of database (Mysql). What if we wanted to use some other database like Sqlite or SQL Server or some other ? Well this is where dependency inversion principle comes into play.

To overcome this problem, we need to create an interface (abstraction or contract - see definition of DIP above) which would allow us to use any database with User class. Here is our interface that all databases would implement:

interface DB
{
    public function connect($dsn, $user = '', $pass = '');
    public function query($query);
}

Here is Mysql class now implementing above interface:

class Mysql implements DB
{
    protected $db = null;

    public function connect($dsn, $user = '', $pass = '')
    {
        $this->db = new PDO($dsn, $user, $pass);
    }

    public function query($query)
    {
        return $this->db->query($query);
    }
}

Another database class implementing above interface:

class Sqlite implements DB
{
    protected $db = null;

    public function connect($dsn, $user = '', $pass = '')
    {
        $this->db = new PDO($dsn);
    }

    public function query($query)
    {
        return $this->db->query($query);
    }
}

As you can see both Mysql and Sqlite implement methods imposed by the interface. Finally here is our User class:

class User
{
    private $database = null;

    public function __construct(DB $database)
    {
        $this->database = $database;
    }

    public function getUsers()
    {
        $users = $this->database->query('SELECT * FROM users ORDER BY id DESC');
        print_r($users);
    }
}

Notice that in constructor of above class, we are now passing interface rather than specific type of database.

Now we can use any database for the User class, here is example of Mysql:

$database = new Mysql();
$database->connect('mysql:host=localhost;dbname=test', 'root', '');
$user = new User($database);
$user->getUsers();

And example of Sqlite database class:

$database = new Sqlite();
$database->connect('sqlite:database.sqlite');
$user = new User($database);
$user->getUsers();

Amazing! we can now readily change database to be used with our User class, our User class is much more flexible by following the dependency inversion principle. If client requires to use some other database, no problem we implement one and specify to User class in similar fashion!

As you can see we took basic and common example of code and converted it into re-usable, flexible, modular and testable piece of code.

You might want to read more about S.O.L.I.D principles to write pleasant code and as bonus avoid S.T.U.P.I.D code.

Phexecute has these features:

• PHP Code_Sniffer to easily identify and fix problematic parts of code (through PSR-2)
• Run PHPUnit tests and see results right inside browser
• Run SimpleTest tests
• Uses Symfony VarDumper component easy visualization of vars, arrays, objects
• Ability to save unlimited snippets
• Live PHP error highlighting
• Easy to extend

Screenshots

Main Screen

PHP Code_Sniffer Results

PHPUnit Results

SimpleTest Results

Checkout Phexecute on Github

I had downloaded and started configuring Slim for my needs but then I saw a post by Rob Allen he posted yesterday mentioning that he has created Slim 3 skeleton. It was good because he already had put together all the goodies I needed:

• Built-in Dependency Injection Container (Slim uses Pimple DIC)
• Monolog
• Ability to inject middlewares
• Twig templating engine
• Dependency-Aware Controllers

It provided good base to start with. I modified his skeleton a bit:

• Added Tracy PHP debugger
• Added nice-looking interface
• Created Twig templates with partials
• Modified folder structure a bit so that both frontend and backend assets can easily be added and used

This now allows me to easily start working on my project.

Here is screenshot of default page of Slim 3 skeleton I created:

Slim 3 Skeleton on Github

One of the simplest design patterns is the Singleton. The purpose of Singleton design pattern is to always have a single instance of a some class. Singletons are usually used for things you don't necessarily need multiple instances of such as database or logging or similar. You always work with same instance of a singleton object.

This is how you create a singleton:

class MySingleton
{
    public static function getInstance()
    {
        static $instance;

        if (null === $instance) {
            $instance = new self();
        }

        return $instance;
    }

    // prevent creating multiple instances due to "private" constructor
    private function __construct(){}

    // prevent the instance from being cloned
    private function __clone(){}

    // prevent from being unserialized
    private function __wakeup(){}
}

Usage:

$instance = MySingleton::getInstance();

Following the same pattern, you can create your own singletons and add any necessary functionality you want. The main trick here is that we have made the constructor private which is what disallows creation of multiple instances of singleton class.

It is important to point out that Singleton design pattern is considered anti-pattern (and more so in the world of PHP) because of following reasons:

• Singletons create global state which is bad; they create tight-coupling
• Singletons are essentially class-oriented not object-oriented
• We cannot tell what dependencies it contains, it hides logic
• Because you cannot create multiple instances, you cannot easily test them
• PHP runs on shared nothing architecture which essentially means unlike other languages like Java/.Net, life of a PHP application is just one http request which is why singletons do not make much sense in PHP

Having said that, many argue that you can at least use singletons for single-nature things like an instance of database or logging (though it is matter of personal preference on how you design database or logging stuff) while others avoid singletons completely (especially TDD Worshipers).

That's all there is to a singleton.

Multiton

As the name suggests, a multiton is a design pattern that helps you create multiple instances of itself. Both singleton and multiton are same, the only difference is that a multiton can store and retrieve multiple instances of itself. Obviously multiton suffers from same problems as singletons.

Here is example of multiton:

class Logger
{
    private static $instances = array();

    public static function getInstance($key)
    {
        if(!array_key_exists($key, self::$instances)) {
            self::$instances[$key] = new self();
        }

        return self::$instances[$key];
    }

    // prevent creating multiple instances due to "private" constructor
    private function __construct(){}

    // prevent the instance from being cloned
    private function __clone(){}

    // prevent from being unserialized
    private function __wakeup(){}
}

Usage:

$firstInstance = Logger::getInstance('file');
$secondInstance = Logger::getInstance('email');

Factory design pattern works like a factory in the real world in that it creates something for others to use. In the context of OOP, it helps in creating and instantiating objects.

Example

Let's say for our application we are using different types of databases based on requirement such as MySQL, PostgreSQL, and SQLite. Our classes look like this:

MySQL:

class MySQLDB
{
    public function setHost($host)
    {
        // code
    }
    public function setDB($db)
    {
        // code
    }
    public function setUserName($user)
    {
        // code
    }
    public function setPassword($pwd)
    {
        // code
    }
    public function connect()
    {
        // code
    }
}

PostgreSQL:

class PostgreSQLDB
{
    public function setHost($host)
    {
        // code
    }
    public function setDB($db)
    {
        // code
    }
    public function setUserName($user)
    {
        // code
    }
    public function setPassword($pwd)
    {
        // code
    }
    public function connect()
    {
        // code
    }
}

...and so on for SQLite database.

Then we instantiate different objects based on configuration:

if (Config::item('db_type') === 'mysql') {
    $DB = new MySQLDB();
    $DB->setHost("host");
    $DB->setDB("db");
    $DB->setUserName("user");
    $DB->setPassword("pwd");
    $DB->connect();
}
elseif (Config::item('db_type') === 'postgre') {
    $DB = new PostgreSQLDB();
    $DB->setHost("host");
    $DB->setDB("db");
    $DB->setUserName("user");
    $DB->setPassword("pwd");
    $DB->connect();
}
elseif (Config::item('db_type') === 'sqlite') {
    $DB = new SQLiteDB();
    $DB->setHost("host");
    $DB->setDB("db");
    $DB->setUserName("user");
    $DB->setPassword("pwd");
    $DB->connect();
}

Generally above works but it creates problems in rather big applications. Above code has these problems:

• Should you add more database types, code would keep on growing making it complex
• The code is hard coded with database type names
• Whole process becomes tedious

To solve these issues, we can instead create a central factory object that would create those objects for us:

class DBFactory
{
    protected $driver = null;

    public function setDriver($driver)
    {
        $this->driver = $driver;
    }

    public function makeDB($host, $user, $pass, $dbname)
    {
        if ($this->driver === 'mysql') {
            $DB = new MySQLDB();
        }
        elseif ($this->driver === 'postgre') {
            $DB = new PostgreSQLDB();
        }
        elseif ($this->driver === 'sqlite') {
            $DB = new SQLiteDB();
        }

        $DB->setHost($host);
        $DB->setDB($dbname);
        $DB->setUserName($user);
        $DB->setPassword($pass);
        $DB->connect();

        return $DB;
    }
}

And then using it:

$dbFactory = new DBFactory;
$dbFactory->setDriver(Config::item('db_type'));
$DB = $dbFactory->makeDB("host", "db", "user", "pwd");

And that's it. You won't have to modify above code, it will always remain same, we have moved the complex object creation logic separate in the factory itself which now makes our code a lot more easier to work with.

Please notice that there are some variations of factory design pattern such as simple factory, abstract factory and factory method. In this example, we used the factory method eg we used a method named makeDB() to create our objects. Other variations are almost similar; for example with abstract factory, you actually create an abstract class and then all concrete classes should extend it. It just enforces commonality between similar concrete classes.

Note: In modern day, the object creation has become very simple with the help of Dependency Injection Containers and Service Locators. There are quite some DICs to choose from for PHP.

StackOverflow can help you get started by providing you with information such as history of some language/technology, books, references, commonly asked questions and tools, videos and more. Here is the format of the URL you can go to and find out useful information about certain language or technology:

http://stackoverflow.com/tags/TECHNOLOGY/info

In above URL, replace TECHNOLOGY with what you want to learn about such as javascript, php, .net, etc

Here are few examples:

• http://stackoverflow.com/tags/language-agnostic/info
• http://stackoverflow.com/tags/javascript/info
• http://stackoverflow.com/tags/php/info
• http://stackoverflow.com/tags/.net/info
• http://stackoverflow.com/tags/node.js/info
• http://stackoverflow.com/tags/java/info
• http://stackoverflow.com/tags/android/info
• http://stackoverflow.com/tags/iphone/info
• http://stackoverflow.com/tags/bash/info

Of course, you can replace tag in above URL from various tags to choose from.

When I first saw Laravel framework, I really liked its Artisan console tool, it seemed like magic providing us with a bunch of stuff we could do with it such as creating MVC triads, running migrations and a lot more. Although similar concepts already existed in frameworks like CakePHP but Laravel did good job of making us realize how useful a console app can be and that we can use it beyond basic CRUD operations.

To create a console app, we can use Symfony's console component and in fact Laravel also uses the same. We could also use Aura.Cli from AuraPHP but for this post, we will stick with one provided by Symfony.

Installing Symfony Console Component

The easiest way to install it is via composer. Create a new folder in your document root named consoleApp and inside it create composer.json file with these contents:

{
    "require" :{
        "symfony/console": "2.6.7"
    }
}

and then run composer install command in newly created folder from your cli application. After some while you should have vendor directory created.

Creating Our First Command

A command is something that performs an specific task. For example, in Laravel's artisan tool, you can type this:

> php artisan app:name yourAppName

Here app:name is a command that can changes namespace of your Laravel application. Here is also breakdown of above line:

• php - php executable (php.exe). This assumes you have already added php.exe in your PATH enviroment variable in your system
• artisan - The name of the console application
• app:name - The name of the command that will be run
• yourAppName is an argument to the app:name command

Create a Commands folder in root of application, this will contain all our commands for the console app we will be creating. Also create empty file called app (without extension) either by using editor of your choice or running this command via your cli in app root folder touch app. The folder structure should now look like this:

Open app app file in editor of your choice and paste this line in it:

#!/usr/bin/env php

This tells the system that is a php env file and should be run by php executable. You may need to apply execute permission on this file if you are on Linux.

Next, let's include our dependencies through composer's autoload feature, so add this line:

require __DIR__ . '/vendor/autoload.php';

This will automatically include our dependencies which in this case is Symfony Console Component.

By now app file should have these contents:

#!/usr/bin/env php
<?php
require __DIR__ . '/vendor/autoload.php';

Before we edit this file further, let's first create our command which will basically be a Greet command. Our commands will essentially be class files therefore inside Commands directory that we created earlier, create a file called GreetCommand.php.

The Symfony Console Component requires that we should extend it and provide at least two methods called configure() and execute(). As the names suggest, the configure() method can be used to configure our command such as what command will be called, what arguments and options it will accept and the execute() command will actually execute our command.

In GreetCommand.php file, paste in these contents:

<?php
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputArgument;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Output\OutputInterface;

class GreetCommand extends Command
{
    protected $commandName = 'app:greet';
    protected $commandDescription = "Greets Someone";

    protected $commandArgumentName = "name";
    protected $commandArgumentDescription = "Who do you want to greet?";

    protected $commandOptionName = "cap"; // should be specified like "app:greet John --cap"
    protected $commandOptionDescription = 'If set, it will greet in uppercase letters';    

    protected function configure()
    {
        $this
            ->setName($this->commandName)
            ->setDescription($this->commandDescription)
            ->addArgument(
                $this->commandArgumentName,
                InputArgument::OPTIONAL,
                $this->commandArgumentDescription
            )
            ->addOption(
               $this->commandOptionName,
               null,
               InputOption::VALUE_NONE,
               $this->commandOptionDescription
            )
        ;
    }

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $name = $input->getArgument($this->commandArgumentName);

        if ($name) {
            $text = 'Hello '.$name;
        } else {
            $text = 'Hello';
        }

        if ($input->getOption($this->commandOptionName)) {
            $text = strtoupper($text);
        }

        $output->writeln($text);
    }
}

The code is pretty much self-explanatory:

• $commandName is the name of our command
• $commandDescription is description/help text for our command
• $commandArgumentName is argument name of our command
• $commandOptionName is option name of our command. The difference between argument and option is that an option is optional one unlike argument and can be specified with --optionName.
• Inside configure() method, we can easily understand how we set command name, argument and options.
• Inside execute() method, we get argument and check to see if it is set. If set, we say Hello Name otherwise we simply say Hello. Then we check if option is provided and if so we upper case it and finally output the result.

Now finally let's tell Symfony Console Component to use our command we just created. Modify app file so it looks like this:

#!/usr/bin/env php
<?php
require __DIR__ . '/vendor/autoload.php';

use Symfony\Component\Console\Application;

$application = new Application();

# add our commands
$application->add(new GreetCommand());

$application->run();

Let's test our command. Open your cli app and point it to our app root and run this command:

> php app app:greet John

That should result in error that GreetCommand.php flle was not found. Let's tell composer to automatically include our commands from Commands folder. Edit composer.json file so it looks like this:

{
  "require": {
    "symfony/console": "2.6.7"
  },
  "autoload": {
    "classmap": ["Commands"]
  }
}

and then type composer dump -o from your cli app. Now run our command again:

> php app app:greet John

and you should see Hello John. Type:

> php app app:greet John --cap

and you should see HELLO JOHN.

Here we named our console file app but if you rename it to artisan and then run above commands replacing app with artisan, you will have your own artisan tool, funny enough :)

Of course, you can now add any commands you want to your new console app. You can even run composer or git commands through your new console app or may be some deployment/build scripts or even system commands. If you are using some MVC framework, you can use this tool to for example create your own way of creating controllers, entity classes, run your custom migrations, call methods from your controllers and more.

If you want to see how Laravel does it all, you can take a look inside this folder and see how those commands are created:

vendor/laravel/framework/src/Illuminate/Foundation/Console

I am currently working on a project powered by CodeIgniter (and it doesn't have built-in console app as you know) and I have created quite some commands that have really helped me speed up my development time where I do a host of different things via my console app.

Have fun with your artisan tool :)

The adapter design pattern as the name suggests is like real life adapter that converts one thing into some other one. Similarly, it can help us wrap functionality of some object into adapter providing us with consistent methods/API to work with. Understanding through an example is always the best way to learn.

Example

Suppose you have developed a website where client has asked you to allow users to post status updates on the Facebook. In order to to that, we use Facebook PHP client library which looks something like this:

class Facebook {    
    public function getUserToken($userId) {
        // code to get user token
    }

    public function postUpdate($message) {
        // code to post status update
    }
}

And then you use it to post updates on Facebook:

$statusUpdate = new Facebook;
$statusUpdate->getUserToken($someUserId);
$statusUpdate->postUpdate('some message');

Now let's assume suddenly client requires that instead of Facebook, he wants users to post updates on Twitter and Twitter's PHP client library looks like this:

class Twitter {    
    public function checkUserToken($userId) {
        // code to get user token
    }

    public function setStatusUpdate($message) {
        // code to post status update
    }
}

And here is the problem. We can see that Twitter's library has different method names which means we will have to modify code everywhere where we are using status updates. At this point, as developer, we should also not overrule the fact that client may again ask to use Facebook again or may be some other service to allow users to post status update but we don't want to change our code again and again.

So how do we make sure that:

• We should be able to add any new service easily when client asks
• We should be able to not modify code again and again, same code should post status updates without modifying it

This is where Adapter pattern comes out to be as life saver. In order to implement that, we first set rules/interface that all status update service should follow so let's create one:

interface iStatusUpdate {
    function getUserToken($userId);
    function postUpdate($message);
}

Now we create our Twitter adapter class:

class TwitterAdapter implements iStatusUpdate {

    protected $twitter;

    public function __construct(Twitter $twitter){
        $this->twitter = $twitter;
    }

    public function getUserToken($userId) {
        $this->twitter->checkUserToken($userId);
    }

    public function postUpdate($message) {
        $this->twitter->setStatusUpdate($message);
    }
}

Notice how we have passed Twitter object via the constructor. Of course we could have used setter or interface injection as well.

We can see that we now have same method names for Facebook and Twitter which means we won't have to modify much code in our codebase where we need to post status updates for users. Now all we need to do is to use our new adapter class providing it with actual Twitter object:

$statusUpdate = new TwitterAdapter(new Twitter);
$statusUpdate->getUserToken($someUserId);
$statusUpdate->postUpdate('some message');

As can be we have added a line or couple but most of status update code remains same, thanks to adapter pattern. We as developers should foresee such changes client may require in which case we would have created adapter class even for our first Facebook service and then we didn't need to modify even a single line of code.

Okay, client asks some other service to use, no problem:

class SomeOtherServiceAdapter implements iStatusUpdate {

    protected $otherService;

    public function __construct(SomeOtherService $otherService){
        $this->otherService = $otherService;
    }

    public function getUserToken($userId) {
        $this->otherService->authenticate($userId);
    }

    public function postUpdate($message) {
        $this->otherService->postMessage($message);
    }
}

And then:

$statusUpdate = new SomeOtherServiceAdapter(new SomeOtherService);
$statusUpdate->getUserToken($someUserId);
$statusUpdate->postUpdate('some message');

Again most of the code remains same.

So these simple examples show how useful and time-saver adapter pattern is. It provides us with consistent API to work with and allows us to use new services easily.

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

So a design pattern is nothing but a re-usable solution towards commonly occurring problems you may face while programming.

Overview

One of the common problems we face in programming is to make decisions based on different conditions/inputs.

Let's say we have created a framework of our own and we want to be able to allow users to choose different types of logging methods such as logging to file, database or email.

Example

First, we create our logger classes for the framework that implement common interface:

interface InterfaceLogger {
    function log($message);
}

class FileLogger implements InterfaceLogger {
    public function log($message) {
        // code to write logging information to file system
    }   
}

class DatabaseLogger implements InterfaceLogger {
    public function log($message) {
        // code to write logging information to database
    }   
}

class EmailLogger implements InterfaceLogger {
    public function log($message) {
        // code to write logging information to email
    }   
}

Let's assume users of our framework are allowed to choose an specific logger through some configuration file by typing file, database or email and our framework is able to know it:

$loggerType = App::getConfig('logger');

Now we can easily find out which logger to use using strategy design pattern:

switch($loggerType) {
    case "file":
        $logger = new FileLogger();
        break;
    case "database":
        $logger = new DatabaseLogger();
        break;
    case "email":
        $logger = new EmailLogger();
        break;
    default:
        $logger = new FileLogger();
}

And then throughout our framework, we can use $logger->log() method which would automatically know which logger type to use.

As you might have noticed, strategy pattern is very simple one and we might have written similar code a number of times before albeit without realizing it is actually some design pattern.

function isAuthorized($userId, $age)
{
    if (isLoggedIn($userId))
    {        
        if (isAdmin($userId) && $age >= 18)
        {            
            if (hasAcess($userId, $resourceId))
            {
                return true;
            }
        }
    }

    return false;
}

Although functionally nothing wrong with above code but it is good practice to avoid nested conditions (also nested loops) in some way or the other. This is simple example that may look easy to grasp to the naked eye, this isn't always the case. Obviously we can refactor above code and avoid nested conditions like this:

function isAuthorized($userId, $age)
{
    if (isLoggedIn($userId) && isAdmin($userId) && $age >= 18 && hasAcess($userId, $resourceId))
    {        
        return true;
    }

    return false;
}

We have shortened the code but still it doesn't look that good and readability is compromised here. Depending on the code editor/IDE you are using and font you are using or if you have even more nested conditions, this doesn't seem good solution or one that is easy to understand.

The solution is something called Guard Clauses which essentially mean you put your conditions in inverted way than your original conditions. Guard clauses should return opposite value compared to your original conditions. Here is how we can use guard conditions with above example:

function isAuthorized($userId, $age)
{
    if (! isLoggedIn($userId)) { return false; }
    if (! isAdmin($userId) || $age < 18) { return false; }
    if (! hasAcess($userId, $resourceId)) { return false; }

    return true;
}

As can be seen, we have got rid of nested conditions by putting reverse conditions on top of the function. We don't proceed any further when any of these is false. If none is false, true is returned as default value in the end.

The benefit here is that code looks easy to understand and gives quick idea of what it is doing at first glimpse. Pretty simple yet effective stuff.

Avoid This ;-)

Well the easiest way to deal with this problem would be to allow users in your application choose their timezones; for example you can present them with a dropdown of all timezones. That's first step.

Now once you know user's timezone, we can easily convert it back and forth. We can use GMT for this purpose because it makes it easy to convert users' timezones. So when saving times to database for example, we would first convert it to GMT. When reading from database and to show on actual webpage, we convert it from GMT to user's actual timezone. This way, we always save times in GMT and show them back to users according to their timezones.

I have made this simple class you can use in your applications:

/**
 * A class to ease timezone managment for users in an applications
 *
 * @author Sarfraz Ahmed <sarfraznawaz2005@gmail.com>
 * @license http://www.opensource.org/licenses/mit-license.html MIT License
 */
class UserTimeZone
{

    /**
     * Time format to be used
     *
     * @var string
     */
    protected $format = null;

    /**
     * Timezone to be used
     *
     * @var string
     */
    protected $defaultTimeZone = null;

    /**
     * @param string $format
     * @param string $defaultTimeZone
     */
    public function __construct($format = 'Y-m-d h:i:s P', $defaultTimeZone = 'UTC')
    {
        $this->format = $format;
        $this->defaultTimeZone = $defaultTimeZone;
    }

    /**
     * Returns all timezones in an array.
     * Can be used to construct a dropdown of all timezones
     * for users to select
     *
     * @return array
     */
    public function getTimeZones()
    {
        return DateTimeZone::listIdentifiers();
    }

    /**
     * Sets dates in GMT format.
     * Should be used when saving dates in database for example.
     *
     * @param $date
     * @return string
     */
    public function setDate($date)
    {
        $date = new DateTime($date, new DateTimeZone($this->defaultTimeZone));
        $date->setTimezone(new DateTimeZone('GMT'));

        return $date->format($this->format);
    }

    /**
     * Gets data based on users' timezones.
     * Should be used when showing dates in pages for example.
     *
     * @param $date
     * @return string
     */
    public function getDate($date)
    {
        $date = new DateTime($date, new DateTimeZone('GMT'));
        $date->setTimezone(new DateTimeZone($this->defaultTimeZone));

        return $date->format($this->format);
    }
}

It is self-explanatory. Read the comments in class please.

Usage:

$format = 'd-m-Y h:i:s';
$userTZ = 'Asia/Karachi'; // user's time zone
$tz = new UserTimeZone($format, $userTZ);

$date = $tz->setDate('2015-01-01 6:32 PM');
// save $date in db for example

$date = $tz->getDate('2015-01-01 9:32 PM');
// show $date on webapge for example

1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backwards-compatible manner
3. PATCH version when you make backwards-compatible bug fixes

Let's take example of Symfony framework which follows SemVer. As of this writing, its stable version stands at 2.6.6

Symfony Versioning

+-------+---------+
| Name  | Version |
+-------+---------+
| MAJOR | 2       |
+-------+---------+
| MINOR | 6       |
+-------+---------+
| PATCH | 6       |
+-------+---------+

Here, we can see that MINOR and PATCH versions are backwards-compatible. This means if you install Symfony version 2.0.0 or 2.x.x with x being any number, it will be backwards-compatible. Meaning if you had initially installed Symfony version 2.0.0 and now you want to install version 2.6.6, you can do so without worrying it breaking functionality. However when Symfony announces a version starting with 3 as MAJOR version then it will most likely break some of the functionality with all previous version less than 3.x.x. Thanks to SemVer, we can easily find that out now. Not to mention, almost all nicely written frameworks or libraries or software in general now follow SemVer. Please read more about it.

As a PHP developer, composer is something we can't do without these days. If you think you are a PHP developer and haven't started using composer yet, you are not a PHP developer DOT In that case, search on Google on what it is and its tutorials or see its official documentation. In short, it is package manager for PHP that has superseded older methods such as PEAR, etc. It is like NPM for NodeJS or RubyGem for Ruby developers.

Let's say I want to install Symfony via composer, I can specify specific version to use in quite some ways like:

+--------------------------------+----------------------------------------------------------------+
| Version                        | Description                                                    |
+--------------------------------+----------------------------------------------------------------+
| symfony/symfony: "2.6.6"       | Exact 2.6.6 version                                            |
+--------------------------------+----------------------------------------------------------------+
| symfony/symfony: ">= 2.6"      | Any version greater than or equal to 2.6 like 2.6.7, 6.6.9     |
+--------------------------------+----------------------------------------------------------------+
| symfony/symfony: ">= 2.6,<3.0" | Any version greater than or equal to 2.6 but less than 3 Major |
+--------------------------------+----------------------------------------------------------------+
| symfony/symfony: "2.*"         | Any version as long as Major version is 2                      |
+--------------------------------+----------------------------------------------------------------+
| symfony/symfony: "*"           | Latest version                                                 |
+--------------------------------+----------------------------------------------------------------+
| symfony/symfony: "dev-master"  | Latest version from "master" branch                            |
+--------------------------------+----------------------------------------------------------------+
| symfony/symfony: "dev-testing" | Latest version from "testing" branch                           |
+--------------------------------+----------------------------------------------------------------+

We can also use special tilde character ~:

+---------------------------+-----------------------------------------------------------------------+
| Version                   | Description                                                           |
+---------------------------+-----------------------------------------------------------------------+
| symfony/symfony: "~2.6.6" | Any version starting from 2.6.0 to 2.6.x with x being any number      |
+---------------------------+-----------------------------------------------------------------------+
| symfony/symfony: "~2.6"   | Any version starting from 2.0 to 2.x or 2.x.x with x being any number |
+---------------------------+-----------------------------------------------------------------------+
| symfony/symfony: "~2"     | Any Major version greater than or equal to 2 like 2.x or 5.x.x        |
+---------------------------+-----------------------------------------------------------------------+

Once you know how to specify versions in composer, you can easily make sure you are only installing those packages that are backwards-compatible unless you want fresh installation of some package. Similarly, if you have wrote some package, you should choose versioning sensibly so that users of your package don't go incompatible accidentally if you have not made Major changes to your package.

By the way, here is extremely useful Composer cheat sheet, have fun !

Background

Let's start with bit of background. If you worked on PHP's DOM, PDO, MySQLi or some other extensions or frameworks such as Symphony, Laravel, Slim or any other third party libraries, you might have noticed usually they throw their own exceptions:

$dsn = 'mysql:dbname=testdb;host=127.0.0.1';
$user = 'dbuser';
$password = 'dbpass';

$dbh = new PDO($dsn, $user, $password);
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

In case of wrong database connection, it would throw PDOException:

PDOException: SQLSTATE[HY000] [1045] Access denied for user 'dbuser'@'localhost'

Where did PDOException come from ? Or how did PDO gave that exception ? It is simple. As I had pointed out in my previous post, Exception is a class like any other normal class that can be extended. That's exactly what PDO does here, it simply extends the Exception class so PDO extension should be doing something like this under the hood to be able to throw PDOException:

class PDOException extends Exception {}

And that's usually it. And then PDO should now be throwing that new exception instead of Exception:

// something went wrong
throw new PDOException('message here');

And then user of PDO sees those PDOExceptions.

Now that we know PDOException actually extends Exception, we can come to conclusion that we can catch exceptions thrown by PDO either by using PDOException or Exception through nested catch blocks. If exception is NOT caught for PDOException, it will fall back to base Exception:

try{
    // any PDO code here
}
catch(PDOException $e){
    // handle PDOException
}
catch(Exception $e){
    // handle Exception
}

Throwing Your Own Exceptions

As said above, we can throw our own exceptions by extending the Exception class:

class MyAwesomeLibraryException extends Exception {}

or

class MyCompanyException extends Exception {}

That's easy but one might ask why throw custom exceptions? I can see these reasons:

• It makes it easy to recognize which thing (library, class, extension, etc) generated exception in code hierarchy
• This helps developer of orginal library easily spot problems in their code
• It brands your library exceptions like PDO, DOM, etc do.

Now as developer of some library/application, any time we find we need to throw exception, we simply throw our own custom exceptions:

// something wrong, throw our custom exception
throw new MyAwesomeLibraryException('some message');

Of course you can have many exception types as well for your application if you want.

Prioritizing Your Own Exceptions

Imagine we want to create our own ORM library called SuperORM and it uses PDO under the hood. We create our custom exception first:

class SuperORMException extends PDOException {}

And now we throw SuperORMException exception from whole of our ORM where needed. But since we are using PDO under the hood, we get its PDOException as well and we don't want to show this directly to the consumers of our SuperORM library, we want to be able to first show them our own exception type. This is how we can do that:

class SuperORMException extends PDOException {}

class SuperORM {
    public function connect($dsn, $user, $password) {
        // try connecting to database
        try {
            $dbh = new PDO($dsn, $user, $password);
            $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }
        catch (PDOException $e) {
            throw new SuperORMException($e->getMessage(), null, $e);
        }        
    }
}

$dsn = 'mysql:dbname=testdb;host=127.0.0.1';
$user = 'dbuser';
$password = 'dbpass';

$superORM = new SuperORM;
$superORM->connect($dsn, $user, $password);

And that would result in our SuperORMException:

SuperORMException: SQLSTATE[HY000] [1045] Access denied for user 'dbuser'@'localhost'

And consumer of our SuperORM can catch our exception now:

try {
    $dsn = 'mysql:dbname=testdb;host=127.0.0.1';
    $user = 'dbuser';
    $password = 'dbpass';

    $superORM = new SuperORM;
    $superORM->connect($dsn, $user, $password);
}
catch (SuperORMException $e) {
    echo $e->getMessage();
}

This makes sure consumer of library will now know that SuperORM will always throw exception of type SuperORMException.

We see that SuperORMException extends PDOException and PDOException extends Exception, this gives consumer the opportunity to catch exceptions in those types like so:

try {
    $dsn = 'mysql:dbname=testdb;host=127.0.0.1';
    $user = 'dbuser';
    $password = 'dbpass';

    $superORM = new SuperORM;
    $superORM->connect($dsn, $user, $password);
}
catch (SuperORMException $e) {
    // code to catch exception
}
catch (PDOException $e) {
    // code to catch exception
}
catch (Exception $e) {
    // code to catch exception
}

So that's how you can throw your own custom exceptions. In fact that's how some of the ORMs or database libraries from various framework do and throw their own exceptions for consumers to catch.

Don't Always Throw Your Custom Exceptions

By this I mean there are certain exceptions types that are part of Standard PHP (SPL) known as SPL Exceptions. They are made to be thrown for specific reasons and considered best practice. You should throw SPL Exceptions where applicable instead of your own custom exceptions. Here they are:

• LogicException (extends Exception)
  • BadFunctionCallException
    • BadMethodCallException
  • DomainException
  • InvalidArgumentException
  • LengthException
  • OutOfRangeException
• RuntimeException (extends Exception)
  • OutOfBoundsException
  • OverflowException
  • RangeException
  • UnderflowException
  • UnexpectedValueException

As can be seen, those exceptions can be broadly divided into two main categories: LogicException and RuntimeException. All of those exceptions are self-explanatory from their names. For example LogicException represent any errors caused by the logical errors in your code, RuntimeException represent any errors that are caused after script has run eg runtime errors; similarly BadMethodCallException exception should be thrown if a method in your class doesn't exist and so on.

These SPL exceptions are excellent addition to PHP core because previously if call was made to some method which didn't exist, you usually communicated that to user through a message like:

throw new Exception('Method does not exist!');

So you communicated through those messages for different types of problems. The problem here was that we needed specific exceptions; if method didn't exist, we needed BadMethodCallException exception. This clearly tells developer what type of exception it is and why it might have come about. Another benefit is that such exceptions are useful even for Non-English speaking developers who can also easily spot the problem. Therefore, you must use SPL exceptions for different situations they are made for.

At first thought, the words errors and exceptions give the general idea that they are the same thing or collectively errors especially to the beginners. For example, when we see this:

Fatal error: Call to undefined method Foo::bar()

Or this:

Exception: Method is not callable by this object

Most beginner developer would concluded that those are just errors that need to be fixed and that may be right in a superficial sense because both of those messages are bad and need to be fixed anyway but in reality they are different things. The first one is an Error while later one is an Exception. Once we understand there can be both errors and exceptions and how to successfully handle each, we can surely write better code.

In this post, we will see how we can deal with both of them and even create our own custom error and exception handlers for more control over how we want them to be displayed or handled while following best practices.

Difference between Errors and Exceptions

Errors

• Errors are errors that are emitted by the programming language and you need to fix them.

• There can be syntax errors or logic errors. In PHP, there are different levels of errors such as ERROR, PARSE, WARNING, NOTICE, STRICT. Some errors levels halt the further execution of your PHP script (such as FATAL errors) while others allow it to continue while presenting useful information that might also need to be fixed or payed attention to such as WARNING or NOTICE. And finally there are other error levels that can tell whether a particular function is deprecated (DEPRECATED) or whether or not standards are being followed (STRICT).

• Errors can be converted into user-thrown exceptions while still some being recoverable other not because they are emitted by core programming language

• We can emit custom/user errors through trigger_error() function

• We can create custom error handler for all errors using set_error_handler()

• The error_get_last function can be used to get any error that happened last in PHP code. The $php_errormsg variable can be used to get previous error message.

Exceptions:

• Exceptions are object oriented approach to errors and are thrown intentionally by code/developer and should be handled/caught using try - catch -finally blocks

• An Exceptionis a standard class that can be used like any other class and can also be extended.

• Exceptions can have many types (through sub-classes) while errors can only have levels mentioned above.

• Exceptions can be caught at any point in the call stack and can also be caught at root/default exception handler. In comparison, errors are only handled in pre-defined error handler.

• We can throw custom/user exceptions by using throw new Exception(...)

• We can create custom exception handler for all exceptions using set_exception_handler()

General Practice

Nowadays, it seems common (and better) practice to always throw exceptions (even for errors) from your code so that they can be caught and dealt with in caller script. Of course if we throw an exception for error which is FATAL, we can't recover from it but we can still provide OOP approach to caller script. If you have used MySQL extension, you would notice that it emits normal errors if something goes wrong; here is an example when connection to database could not be made:

Warning: mysql_connect(): Access denied for user 'root'@'localhost'

Notice that it emits error level of Warning. This is just an example for the function mysql_connect but other functions of MySQL extension also emit errors in the same way and can be grabbed with mysql_error() function.

But if you use improved version of MySQL called MySQLi or even PDO, you would notice they can now also throw exceptions, here is same example if connection could not be made to database using mysqli:

mysqli_report(MYSQLI_REPORT_STRICT); // tell mysqli to generate exceptions as well
mysqli_connect('localhost', 'root', 'wrongPassword', 'test');

It would give you both error as well as exception:

Fatal error: Uncaught exception 'mysqli_sql_exception' with message 'Access denied for user 'root'@'localhost'

mysqli_sql_exception: Access denied for user 'root'@'localhost' (using password: YES)

So these days any good written package or library or some extension you use, it would most likely generate Exceptions of its own type so that they can be caught and handled gracefully.

How Do Exceptions Help ?

Let's understand through example. Let's say you want to connect to database using mysql and you would normally do something like this:

mysql_connect('localhost', 'root', 'wrongPassword', 'test');

If connection could not be made to database, you would receive error:

Warning: mysql_connect(): Access denied for user 'root'@'localhost'

Now the only thing you can do is go to your code and edit it to specify correct database credentials.

Let's now do the same thing using mysqli:

mysqli_report(MYSQLI_REPORT_STRICT); // tell mysqli to generate exceptions as well
mysqli_connect('localhost', 'root', 'wrongPassword', 'test');

This would generate an error as well as exception as shown previously. Since exception is generated, we can catch it and show the message:

try {    
    mysqli_connect('localhost', 'root', 'wrongPassword', 'test');
} catch (mysqli_sql_exception $e) {
    echo $e->getMessage();
}

The reason why exception is useful here is because you are given a chance to catch that exception gracefully. Inside catch block, we can handle the exception however we want. For the sake of example, let's say we want to connect to database again with correct password this time:

mysqli_report(MYSQLI_REPORT_STRICT);

try {    
    mysqli_connect('localhost', 'root', 'wrongPassword', 'test');
} catch (mysqli_sql_exception $e) {
    mysqli_connect('localhost', 'root', 'rightPassword', 'test');
}

And thanks to exception, we were able to catch it and handle it the way we needed and we are now connected to database which was simply not possible with previous example using mysql which only emitted an error and we couldn't do much. Of course in real world applications, you might not have different passwords to connect to database but this example just gives an idea of how exceptions can be useful.

As another example, let's say we want read feed/rss of some website using SimpleXML (which can also throw exceptions) and store 10 posts in an array:

$feedUrl = 'http://some_feed_url';
$feeds = file_get_contents($feedUrl);
$xml = new SimpleXmlElement($feeds);

$articles = array();
foreach ($xml->channel->item as $item) {
   $item = (array) $item;
   $articles[] = array('title' => $item['title'], 'link' => $item['link']);
}

$data['articles'] = array_slice($articles, 0, 10);

This would work as long as feed url is correct and has posts but if url is wrong, you would see a Fatal error as well Exception being generated by the script:

Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML

Exception: String could not be parsed as XML

Since it is FATAL error, our script died at that point and we can't do anything. How do we ensure that our script continues working and runs any code below that feed code even if provided feed url was wrong ? Of course we need to catch the exception since as we saw it also generated an Exception:

try {
    $feedUrl = 'http://some_feed_url';
    $feeds = file_get_contents($feedUrl);
    $xml = new SimpleXmlElement($feeds);

    $articles = array();
    foreach ($xml->channel->item as $item) {
       $item = (array) $item;
       $articles[] = array('title' => $item['title'], 'link' => $item['link']);
    }

    $data['articles'] = array_slice($articles, 0, 10);
} catch (Exception $e) {

}

echo 'Hello World';

And now since we have wrapped our code in try-catch and caught the exception, our code below that should still run. In this case even if feed url was wrong, you should still see the Hello World message. Our script didn't die and continued its execution. So those two examples should now give idea of how useful exceptions can be when used.

How do I convert Errors into Exceptions?

To do so ,we can use the set_error_handler() function and throw exceptions of type ErrorException something like:

set_error_handler(function ($errorNumber, $errorText, $errorFile, $errorLine ) 
{
    throw new ErrorException($errorText, 0, $errorNumber, $errorFile, $errorLine);
});

With that custom exception now in place, you can do things like:

try {
    // wrong url
    file_get_contents('http://wrong_url');
} catch (ErrorException $e) {
    // fix the url
    file_get_contents('http://right_url');
}

So in catch block, we are now able to fix the URL for the file_get_contents function. Without this exception, we could do nothing but may be suppressing the error by using error control operator @.

Universal Exception Handler

Now that we have seen how useful exceptions are and how to convert errors into exceptions, we can create our custom universal exception handler that can be used throughout the application. It will always generate exceptions not errors. It will do these things:

1 - Allow us to tell it our environment which can be either development or production

2 - In case of production environment, it will log all errors to a file instead of displaying them on screen

3 - In case of development environment, it will display all errors on the screen

/**
 * A class that handles both errors and exceptions and generates an Exception for both.
 *
 * In case of "production" environment, errors are logged to file
 * In case of "development" environment, errors are echoed out on screen
 *
 * Usage:
 *
 * new ExceptionHandler('development', '/myDir/logs');
 *
 * Note: Make sure to use it on very beginning of your project or bootstrap file.
 *
 */
class ExceptionHandler {
    // file path where all exceptions will be written to
    protected $log_file = '';
    // environment type
    protected $environment = '';

    public function __construct($environment = 'production', $log_file = 'logs')
    {
        $this->environment = $environment;
        $this->log_file = $log_file;

        // NOTE: it is better to set ini_set settings via php.ini file instead to deal with parse errors.
        if ($this->environment === 'production') {
            // disable error reporting
            error_reporting(0);
            ini_set('display_errors', false);
            // enable logging to file
            ini_set("log_errors", true);
            ini_set("error_log", $this->log_file);
        }
        else {
            // enable error reporting
            error_reporting(E_ALL);
            ini_set('display_errors', 1);
            // disable logging to file
            ini_set("log_errors", false);
        }

        // setup error and exception handlers
        set_error_handler(array($this, 'errorHandler'));
        set_exception_handler(array($this, 'exceptionHandler'));        
    }

    public function exceptionHandler($exception)
    {
        if ($this->environment === 'production') {
            error_log($exception, 3, $this->log_file);
        }

        throw new Exception('', null, $exception);
    }

    public function errorHandler($error_level, $error_message, $error_file, $error_line)
    {
        if ($this->environment === 'production') {      
            error_log($message, 3, $this->log_file);
        }

        // throw exception for all error types but NOTICE and STRICT
        if ($error_level !== E_NOTICE && $error_level !== E_STRICT) {
            throw new ErrorException($error_message, 0, $error_level, $error_file, $error_line);
        }        
    }
}

Test it:

// register our error and exceptoin handlers
new ExceptionHandler('development', 'logs');

// create error and exception for testing
trigger_error('Iam an error but will be converted into ErrorException!');
throw new Exception('I am an Exception anyway!');

So that is an example of basic universal error and exception handler class. Actually you can do a lot more like customizing the display of messages, getting the stack trace as well as code that caused it, creating timestamp for when those events take place, etc. You should checkout the official documentation in order to achieve those goodies. At any point in your code, you want to restore original PHP's error and exception handlers, you can use restore_error_handler() and restore_exception_handler() functions.

Conclusion

No exception to exceptions!

As a side note, I personally hope someday a PSR standard is created for handling errors and exceptions and their best practices because they are integral part of any PHP code.

// file: CI.php
ob_start();
require_once 'index.php'; // adjust path accordingly
ob_get_clean();
return $CI;

Here we are including index.php file of main CI application. We are using buffering functions here so we don't see actual CI application page and finally we we return the $CI instance so that in any page where we need CI instance, we can simply include this file there. So to use it in some other script, you would simply include above file there:

$CI = require_once 'CI.php';
echo $CI->config->item('base_url'); // test CI instance

That should work for the most cases.

I happen to need CI instance in a cli/console application but above method didn't do the trick for me in console app. So here is another very very hacky way of getting instance of CI in a console app that I was able to come up with after analyzing CodeIgniter code:

// Hacky Way of Accessing CI Instance Outside

error_reporting(1);

$environment = 'development';

$system_path = 'system';

$application_folder = 'application';

if (realpath($system_path) !== false) {
    $system_path = realpath($system_path) . '/';
}

$system_path = rtrim($system_path, '/') . '/';

define('BASEPATH', str_replace("\\", "/", $system_path));
define('APPPATH', $application_folder . '/');
define('EXT', '.php');
define('ENVIRONMENT', $environment ? $environment : 'development');

require(BASEPATH .'core/Common.php');

if (file_exists(APPPATH.'config/'.ENVIRONMENT.'/constants.php')) {
    require(APPPATH.'config/'.ENVIRONMENT.'/constants.php');
} else {
    require(APPPATH.'config/constants.php');
}

$GLOBALS['CFG'] =& load_class('Config', 'core');
$GLOBALS['UNI'] =& load_class('Utf8', 'core');

if (file_exists($basepath.'core/Security.php')) {
  $GLOBALS['SEC'] =& load_class('Security', 'core');
}

load_class('Loader', 'core');
load_class('Router', 'core');
load_class('Input', 'core');
load_class('Lang', 'core');

require(BASEPATH . 'core/Controller.php');

function &get_instance() {
    return CI_Controller::get_instance();
}

$class = 'CI_Controller';
$instance = new $class();

return $instance;

As said above, this is extremely hacky way and may or may not work in all cases and you would also need to adjust paths in above code and/or load more libraries/helpers/etc you need by modifying it.

Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way which reduces complexity, and avoids the typical problems associated with multiple inheritance and Mixins.

So what does this mean ? Let's understand through practical example. Imagine we have chat application and database contains two tables; users and messages and we want to be able to have CRUD functionality for each of those entities. Here is how model class for User looks:

class User {
    protected $table = 'users';

    public function getAll() {
        return DB::getAll($this->table);
    }

    public function get($id) {
        return DB::get($this->table, $id);
    }

    public function add($data) {
        return DB::add($this->table, $data);
    }

    public function update($id) {
        return DB::update($this->table, $id);
    }

    public function remove($id) {
        return DB::remove($this->table, $id);
    }
}

Message model class:

class Message {
    protected $table = 'messages';

    public function getAll() {
        return DB::getAll($this->table);
    }

    public function get($id) {
        return DB::get($this->table, $id);
    }

    public function add($data) {
        return DB::add($this->table, $data);
    }

    public function update($id) {
        return DB::update($this->table, $id);
    }

    public function remove($id) {
        return DB::remove($this->table, $id);
    }
}

At first glance, we can see that both of these classes have exactly the same code for those five methods with only difference of $table being different. This smells and to follow the principle of Don't Repeat Yourself, we can use inheritance of course. So we create a new abstract class that will contain common functionality in the form of those five methods and then both classes would extend this base class:

abstract class Model {     
    public function getAll() {
        return DB::getAll($this->table);
    }

    public function get($id) {
        return DB::get($this->table, $id);
    }

    public function add($data) {
        return DB::add($this->table, $data);
    }

    public function update($id) {
        return DB::update($this->table, $id);
    }

    public function remove($id) {
        return DB::remove($this->table, $id);
    }
}

And now our User and Message classes look like this:

class User extends Model {
    protected $table = 'users';
}

class Message extends Model {
    protected $table = 'messages';
}

And that's it, now both of these classes inherit those five methods from the base Model class, no need to repeat them now, perfect !

Now imaging that suddenly clients requires that some of the fields in both of those tables should be encrypted. For that we create a class that contains two methods encrypt() and decrypt():

class Encoder {
    public static function encrypt($text, $key) {
        // code to encrypt text
    }

    public static function decrypt($text, $key) {
        // code to decrypt text
    } 
}

But how do we use it now ? First thought would be to use it as needed:

$user = new User();
$user->add(array('email' => 'foo@bar.com', 'password' => Encoder::encrypt('some_password', 'key')));

This sounds okay but wouldn't it be better whenever we add a user, it should automatically apply encrypt() for the password field or other fields that we want? It would certainly help us save time and keep from repeating code of encrypt() and decrypt() whenever we operated on such field. So to achieve that we extend our classes with this functionality as well:

// wrong code...
class User extends Model extends Encoder  {
    protected $table = 'users';
}

Of course we can't do above. We can't extend a class with multiple classes since in PHP you can only do single inheritance.

So another thought that comes to mind is to extend Modelclass instead:

abstract class Model extends Encoder {
    // ....
}

And this would certainly work and we would have Encoder functionality available in all our model classes where we can use it the way we need. But think about it. Is it good idea to have Model and Encryption functionality mixed up ? They are totally different things and it doesn't sound like good idea to put encryption logic into your business logic. But then how ? We can use traits !

So let's convert previous Encoder class into a trait:

trait Encoder {
    public static function encrypt($text, $key) {
        // code to encrypt text
    }

    public static function decrypt($text, $key) {
        // code to decrypt text
    } 
}

And to use that trait in some other classes, we need to use it using use Encoder; syntax, so let's add this functionality in our classes:

class User extends Model {
    use Encoder;
    protected $table = 'users';
}

class Message extends Model {
    use Encoder;
    protected $table = 'messages';
}

And now not only our classes inherit functionality from base Model class but also can use the functionality of Encoder trait. We were also able to separate encryption logic from core model logic. So inside our User and Message classes, we can now use $this->encrypt() or $this->decrypt() methods as though they were defined in them (Actually that's what PHP does at runtime). We have been able to overcome the shortcoming of single inheritance.

So now when you re-look the definition of traits given at top of this post, it should make better sense. So traits are noting but a way of code-reuse. To learn more about traits and their characteristics, please refer to its documentation.

Note: One might argue our User and Message classes are also model logic under the hood but this is just an example to give an idea of traits. We could have had controllers or other concrete classes too where we needed common functionality.

class Animal {
    protected $name = 'Animal';

    public function getName() {
        return $this->name;
    }
}

Let's extend the Animal class so we can use its getName() method without repeating it in child class. We will only need the $name variable in child class to get it's name:

class Cat extends Animal {
    protected $name = 'Cat';
}

Now we expect to get names of each object, let's do so:

$animal = new Animal;
$cat = new Cat;

echo $animal->getName(); // Animal
echo $cat->getName(); // Cat

And we successfully get Animal and Cat echoed out. But now let's modify code a bit so that we can use those classes without creating their instances with the help of static keyword (eg global state):

class Animal {
    protected static $name = 'Animal';

    public static function getName() {
        return self::$name;
    }
}

class Cat extends Animal {
    protected static $name = 'Cat';
}

echo Animal::getName(); // Animal
echo Cat::getName(); // Animal

Noticed the problem ? We wanted to see Animal and Cat to be echoed out like previous example but in both cases it said Animal not Cat.

The reason why in previous example things worked the way expected is because we explicitly created new instances of both classes using new keyword and PHP knew which class and method to use. This is not the case in second static example. In the second example, we are using the self keyword which always resolves to current class where it is called. This is reason why the name for the Cat class wasn't echoed out.

So how do we get the name of cat ? Here are few ways.

By Repeating Same Code In Child Class

class Animal {
    protected static $name = 'Animal';

    public static function getName() {
        return self::$name;
    }
}

class Cat extends Animal {
    protected static $name = 'Cat';

    public static function getName() {
        return self::$name;
    }    
}

echo Animal::getName(); // Animal
echo Cat::getName(); // Cat

This works but it defeats the purpose of inheritance. What is the point of extending Animal class when we need to repeat same code in child class ? This isn't ideal.

By Using get_called_class()

class Animal {
    protected static $name = 'Animal';

    public static function getName() {
        $class = get_called_class();
        return $class::$name;
    }
}

class Cat extends Animal {
    protected static $name = 'Cat';
}

echo Animal::getName(); // Animal
echo Cat::getName(); // Cat

This is better and works for our purpose.

By Using static keyword

PHP 5.3 introduced the static keyword to help deal with this issue. Before that, get_called_class() was what was used. Let's get the expected result using static keyword:

class Animal {
    protected static $name = 'Animal';

    public static function getName() {
        return static::$name;
    }
}

class Cat extends Animal {
    protected static $name = 'Cat';
}

echo Animal::getName(); // Animal
echo Cat::getName(); // Cat

And this works fine too. These days using static keyword seems to be common practice instead of get_called_class() to deal with this issue though get_called_class() has many other uses too.

So in simple words, late static binding is something that helps us correctly resolve to static classes at run time. So when we use self keyword, PHP checks it at compile time which class to bind the method call to but when we use static keyword, PHP would check it late eg it would determine which class to use and bind method call to at runtime. Doing it at runtime is what helps PHP determine which class was meant.

$factorial = function( $n ) use ( &$factorial ) {
    if( $n == 1 ) return 1;
    return $factorial( $n - 1 ) * $n;
};

echo $factorial( 5 ); // 120

In that post I simply said it is important to pass $factorial by reference otherwise it won't work. Let's explore why it is so in this post.

Closures are pretty common in Javascript so let's create a simple closure in it and see how it behaves:

var addOne = function(num) {
    return function() { 
        console.log(num++); 
    };
};

var f = addOne(1);

f(); // 1
f(); // 2
f(); // 3

As can be seen, each time we call the function, it increments the number. Let's now convert the same in PHP:

$addOne = function($num) {
    return function() { 
        echo $num++; 
    };
};

$f = $addOne(1);

$f();
$f();
$f();

This would result in error:

Notice: Undefined variable: num

Why is it so ? Because variable scope is different in PHP and Javascript. In PHP, all variables go in local scope by default unless you explicitly declare them in global scope. However in Javascript all variables go in global scope unless you explicitly declare them in local scope using var keyword. Since we are talking about functions and closures here, we can say that in PHP a variable declared in a function can only be available to that function where it is declared. On the other hand, in Javascript a variable can not only be available to function where it is declared but also to inner functions of that parent function. Let's see an example:

function test() {
  $variable = 'value';

  return function() {
    echo $variable;
  };
}

$f = test();
$f(); // Notice: Undefined variable: variable

So PHP gave error as inner function didn't had access to outer variable $variable. We could have made this variable available to inner function either by creating closure using use keyword or declaring that variable in global scope. Le't see same example in Javascript:

function test() {
  var variable = 'value';

  return function() {
    console.log(variable);
  };
}

var f = test();
f(); // value

In Javascript though, the inner function was able to get variable from outer scope eg parent function in this example.

This is reason why Javascript inner function shown above didn't give error whereas PHP's did. Therefore to have access to outer variable in PHP, we need to create a closure by using the use keyword. Of course in Javascript, you don't need something like use keyword because as I mentioned in Javascript a variable of a parent function is available to all its inner functions as well. So we need to use the use keyword in PHP due to difference of variable scoping in PHP and Javascript.

So let's fix that error we received earlier in PHP:

$addOne = function($num) {
    return function() use ($num) { 
        echo $num++; 
    };
};

$f = $addOne(1);

$f(); // 1
$f(); // 1
$f(); // 1

Now we have created the closure and error is gone and $num variable is now available to inner function but there is a problem, each time we call the function it says 1 unlike Javascript example we saw earlier which said 1, 2 and 3. That's because unlike Javascript, PHP creates a new local variable inside inner function eg passes it by value not by reference. Conceptually, PHP sees this code like this:

$addOne = function($num) {
    return function() use ($num) { 
        $num = 1;  // so PHP kind of creates a new variable and assigns to 1 each time you call this
        echo $num++; 
    };
};

So to get similar output as in Javascript, we need to pass the variable using reference which can be done by using the & symbol:

$addOne = function($num) {
    return function() use (&$num) { // passed by reference 
        echo $num++; 
    };
};

$f = $addOne(1);

$f();
$f();
$f();

and now we get the output 1, 2, and 3.

And that's also reason why you needed to pass variable by reference for the factorial example I had given in my previous post. Hope this post clears the confusion of closures and scoping especially for someone who comes from Javascript to PHP.

Quoting from CI documentation:

Migrations are a convenient way for you to alter your database in a structured and organized manner. You could edit fragments of SQL by hand but you would then be responsible for telling other developers that they need to go and run them. You’d also have to keep track of which changes need to be run against the production machines next time you deploy.

Migrations come in extremely handy when you are working with a team of developers. Normally whenever you created a new database table or modified existing one by adding/removing certain fields or even added some data to database, you would tell your fellow developers to run those SQL queries in their machines so that database remains in sync.

This isn't ideal, we needed some way so that:

• Framework (CodeIgniter or whatever) automatically detects and runs those SQL queries on our behalf without handing over SQL query files to other developers each time we make some change to database

• And keeps versions of our database changes similar to versioning of files when we use git. This means we can go back and forth easily to specific version of database changes. Something went wrong on production site and you need to revert to specific database change, no problem simply tell CodeIgniter which change to revert to and you are done.

That's what migrations do.

You now see how important and useful migrations are. One of the first frameworks that really shined up with this idea was Laravel and then I saw similar concept in Android applications. CodeIgniter also allows us to setup migrations which is really cool.

Setting Up Migrations in CodeIgniter

In order to enable migrations:

• Open application/config/migration.php file and set the value for $config['migration_enabled'] from false to true.
• Create a folder called migrations in application/config/ folder and that's it.

In migrations folder, we can create our database changes. Let's say we want to create a new users table. To do so, create a file called 001_add_users.php in migrations folder and paste this code in it:

class Migration_Add_user extends CI_Migration
{
    public function up()
    {
        $this->dbforge->add_field(
           array(
              'id' => array(
                 'type' => 'INT',
                 'constraint' => 5,
                 'unsigned' => true,
                 'auto_increment' => true
              ),
              'name' => array(
                 'type' => 'VARCHAR',
                 'constraint' => '100',
              ),
              'email' => array(
                 'type' => 'TEXT',
                 'null' => true,
              ),
           )
        );

        $this->dbforge->add_key('id', TRUE);
        $this->dbforge->create_table('users');
    }

    public function down()
    {
        $this->dbforge->drop_table('users');
    }
}

There are few things to notice:

• We see that this migration class extends CI_Migration class.
• It has only two methods up() and down()
• It uses dbforge object to build up queries in OOP way
• The migration files should be prefixed with three digits like 001_first_migration.php, 002_second_migration.php and so on

So that's how a typical migration class should look like. But we are only interested in up() and down() methods. The up() method is called by system whenever you need to update the database and down() method is used to revert that change that was done by the up() method. For example, if in up() method you create a new table then in down() method you should specify code to remove that table. Similarly if in up() method you add a new field to some table then in down() method you should specify code that deletes that field. So both of these methods are opposite to each other. In each migration you should always specify the code for both.

Now that we have created our migration, we need to run it. Let's create a controller called Migrate that will run our migrations:

class migrate extends CI_Controller {
    public function index()
    {
        // load migration library
        $this->load->library('migration');

        if ( ! $this->migration->current())
        {
            echo 'Error' . $this->migration->error_string();
        } else {
            echo 'Migrations ran successfully!'
        }   
    }    
}

Now if you visit your application url at http://yoursite.com/migrate and all goes well, you should success message and the new table users should be created in the database. If you run migration for the first time, you would also notice that a table called migrations should also be created in your database by CodeIgniter. This table can keep track of your database migration changes.

Now refresh page or re-visit http://yoursite.com/migrate and you would notice nothing happens, this time CodeIgniter won't do anything with your migration since it has already been run. To prove it further, delete users table manually from your database and then re-visit http://yoursite.com/migrate page and you will see CodeIgniter didn't create users table again. That's because CodeIgniter knows that it has already run that particular migration. Now if you add some other migrations in migrations folder and then visit migrate URL again, this time CodeIgniter will run your new migrations. How does CodeIgniter know which migrations to run ? It keeps track of them migrations table that it creates as well as config['migration_version'] setting in application/config/migration.php file. That's how CodeIgniter versions your database changes.

You see how simple and powerful migrations are. Now that you have made changes to database, you don't need to worry how other team members will embrace those changes, all you need to ask them is to visit the migration url and database on their machines will also get those changes!

In the above example, we used $this->migration->current() method to go to current migration version that is set in config['migration_version']. There are couple of more methods that allow you to migrate based on most recent version of migration based on file system and one that allows you to go to specific migration version. To lean more about dbforge methods, check out its documentation.

So if you have never used database migrations before, you should definitely use them because they are awesome!

The environment may be development, staging, production or some other. Each environment can have different set of settings; for example different application configurations, database settings, email settings, logging, error reporting levels and more. By using different environments for your application, you can actually ease things up for yourself when deploying as you won't have to change configurations, database setting and error reporting levels after application is moved to development or production site. Once you setup different development environments, the system would automatically know your application-wide settings to use.

If you have worked with Laravel, you would notice that you can setup different development environments for your application by specifying your current development environment in the .env file. You can actually have different development environments in CodeIgniter as well.

If you open up index.php file of CodeIgniter, you would notice it sets development environment as default in a constant ENVIRONMENT:

CodeIgniter 2+:

define('ENVIRONMENT', 'development');

CodeIgniter 3+:

define('ENVIRONMENT', isset($_SERVER['CI_ENV']) ? $_SERVER['CI_ENV'] : 'development');

And later in the very file, CI sets up error reporting based on that environment:

if (defined('ENVIRONMENT')) {
    switch (ENVIRONMENT) {
        case 'development':
            error_reporting(E_ALL);
            break;

        case 'production':
            error_reporting(0);
            break;

        default:
            exit('The application environment is not set correctly.');
    }
}

In fact, CI uses ENVIRONMENT constant at quite some places, quoting from its documentation:

There are some places in the CodeIgniter system where the ENVIRONMENT constant is used.

Setting Different Development Environments

Let's say we want to have ability to have different development environment for local, development and production. For example, we want to be able to:

• Have error reporting turned on local and development environments but turned off on production
• Have logging turned on local and development environments but turned off on production
• Have different config settings for each of local, development and production environments
• Have different database settings for each of local, development and production environments
• Have different email settings for each of local, development and production environments

According to CI documentation, in order to setup different environments, you need to create a folder inside application/config folder matching the name of environment. For example, to create development environment, we would create a folder application/config/development.

So create three folders named development, local and production inside application/config folder. And copy config.php, database.php and email.php from application/config to three folders you just created. If email.php doesn't exist, you can create one.

Now each of your config.php, database.php and email.php can have differnt settings. CodeIgniter will automatically choose right files to use based on your current environment. For example in application/config/local/config.php and application/config/development/config.php files, you can enable error reporting and logging using $config['log_threshold'] setting by setting it to 1 but disable error reporting and logging in production environment by setting $config['log_threshold'] to 0 in application/config/production/config.php file. Similarly, you can now easily setup different $config['base_url'] in each of your environments' config.php file like:

application/config/local/config.php:

$config['base_url'] = 'http://localhost/mysite';

application/config/development/config.php:

$config['base_url'] = 'http://mysite.com/development';

application/config/production/config.php:

$config['base_url'] = 'http://mysite.com';

Now when you upload your application, all you have to do is specify which environment you want to use by editing index.php file:

define('ENVIRONMENT', 'production'); 

If you upload your application to production site, set it to production or if you upload it to development,set it to development.

I am sure you don't want to specify your environment for ENVIRONMENT each time you upload/deploy your application, here is how you can do so:

$local_servers = array('localhost');
$isLocal = in_array($_SERVER['SERVER_NAME'], $local_servers);

if ($isLocal) {
    $env = 'local';
} else {
    // check development word in url
    preg_match('#/development#', $_SERVER['REQUEST_URI'], $isDevelopment);

    $env = $isDevelopment ? 'development' : 'production';
}

And then use $env variable:

define('ENVIRONMENT', $env);

So instead of doing this:

class someFrontendController extends CI_Controller {}
class someBackendController extends CI_Controller {}

I should be able to do this:

class someFrontendController extends FrontendController {}
class someBackendController extends BackendController {}

I also need ability to specify common controllers that can be applicable to both frontend and backend:

class someCommonController extends CommonController {}

I will explain benefits of having such controllers below. But for now, how do we do that ? Well CodeIgniter is very flexible and does allow you to achieve just that.

Extending CodeIgniter's CI_Controller Class

In order to have separate controllers for backend, frontend and common controllers, please follow these steps:

1) Make sure that config $config['subclass_prefix'] is set to MY_ in application/config.php file. It should be so by default.

2) Create a file called MY_Controller.php in application/core folder and paste this code in it:

<?php (defined('BASEPATH')) OR exit('No direct script access allowed');

class CommonController extends CI_Controller
{
    public function __construct()
    {
        parent::__construct();
    }
}

class FrontendController extends CommonController
{
    public function __construct()
    {
        parent::__construct();
    }
}

class BackendController extends CommonController
{
    public function __construct()
    {
        parent::__construct();
    }
}

Now for all of your controllers that belong to frontend, you would extend FrontendController instead of CI_Controller and for all of your controllers that belong to backend, you would extend BackendController instead of CI_Controller like I mentioned above:

class someFrontendController extends FrontendController {}
class someBackendController extends BackendController {}

And for any controllers that might share common data for frontend and backend, you would extend CommonController:

class someCommonController extends CommonController {}

What's the Point ?

You might already have guessed the benefits of having separate controllers but if you haven't yet, well here they are:

• You can now easily distinguish which controllers belong to backend and which ones belong to frontend
• You now have ability to have common code for both sides of an application.

By common code, I mean any functionality that you would want to be shared in all of your controllers. Let's assume that we have created login functionality and user is logged on frontend. Now normally you would write some code in all of your controllers (for authorized pages for example) that would check whether or not user is logged in; if user is not logged in, redirect him back to login page something like:

class MyController extends CI_Controller
{
    public function index() {
        // check if user is logged in
        $this->checkLoginStatus();

        // more code of controller when user is logged in
    }

    // redirect user to login page if not logged in
    protected function checkLoginStatus() {
        if (! $this->session->userdata('is_logged_in')) {
            redirect('login');
        }
    }
}

Now for all of your pages that can be viewed only when user is logged in, you will need to insert checkLoginStatus() function in all of those controllers and then call it index() function. That's not good, it is repeating code. Remember the rules Don't Repeat Yourself (DRY) and Keep It Simple, Stupid! (KISS) :)

Let's KISS it; simply put checkLoginStatus() function code in your FrontendController and now all controllers that extend it will have this login check functionality:

class FrontendController extends CommonController
{
    public function __construct()
    {
        parent::__construct();

        // check if user is logged in
        $this->checkLoginStatus();
    }

    // redirect user to login page if not logged in
    protected function checkLoginStatus() {
        if (! $this->session->userdata('is_logged_in')) {
            redirect('login');
        }
    }    
}

And now you don't need to do anything in your normal frontend controllers. You now get login check functionality out of box. In the similar fashion, you can have some common functionality for all of your backend controllers by putting some code in BackendController. This was just an example for login check but of course you could have some other requirement that you wanted to inject in all of your controllers by using FrontendController or BackendController.

You might ask, you could have done all of this by may be using CI Hooks or may be traits, well that's true but I believe having separate controllers gives you more control and separation of concerns.

Similarly, you could put whatever code you want in class for CommonController that would be applicable to both frontend and backend. For example you could setup application's overall configuration, upload paths, logos, etc whatever you think should be available site-wide; in all controllers of backend and frontend.

So anything that you put in FrontendController will be available in all controllers of frontend that extend it. Anything that you put in BackendController will be available in all controllers of backend that extend it. Anything that you put in CommonController will be available in all controllers of frontend + backend.

And finally there is one more problem I don't like personally. Even though we can now easily find out which controllers belong to frontend or backend, we still have to put all of them in application/controllers folder. This doesn't easily tell by looking at file names which controllers belong where unless you open it up and see what it extends. Of course we could use prefix for controller file names like front-foo-controller.php or backend-bar-controller.php but still you have to put them in same folder. It would have been cool if you could have folder structure like this where you can go any nested level while having each distinct part of functionality in its own module:

+ frontend
   + module-one
      + controllers
          - controllers-one.php
          - controllers-two.php
      + models
          - model-one.php
          - model-two.php
      + views
          - view-one.php
          - view-two.php
   + module-two
   + module-three
+ backend
   + module-one
   + module-two
   + module-three

Oh yes you can do that as well with the help of HMVC module for CodeIgniter :)

Note: HMVC is not just about organizing folders, it is whole concept where you get ability to have one controller call some other controller. In HMVC, Each model-view-controller triad represents distinct piece of functionality or mini application which runs independent from other triads.

Have fun!

$this->benchmark->mark('code_start');

// Some code happens here

$this->benchmark->mark('code_end');

echo $this->benchmark->elapsed_time('code_start', 'code_end');

That's fine as long as you need to benchmark specific points/parts in your code.

But if you need to find out overall time page took to load, you can actually use below variable in your views:

{elapsed_time}

Or simply:

<?php echo $elapsed_time;?>

That variable is automatically created by CodeIgniter.

In software engineering, dependency injection is a software design pattern that implements inversion of control for software libraries. Caller delegates to an external framework the control flow of discovering and importing a service or software module specified or "injected" by the caller.

In simple terms, Dependency Injection is a design pattern that helps avoid hard-coded dependencies for some piece of code or software.

The dependencies can be changed at run time as well as compile time. We can use Dependency Injection to write modular, testable and maintainable code:

• Modular: The Dependency Injection helps create completely self-sufficient classes or modules
• Testable: It helps write testable code easily eg unit tests for example
• Maintainable: Since each class becomes modular, it becomes easier to manage it

The Problem

We have dependencies almost always in our code. Consider the following procedural example which is pretty common:

function getUsers() {
     global $database;
     return $database->getAll('users');
}

Here the function getUsers has dependency on the $database variable (tight coupling). It has some of these problems:

• The function getUsers needs a working connection to some database . Whether there is successful connection to database or not is the fate of getUsers function

• The $database comes from outer scope so chances are it might be overwritten by some other library or code in the same scope in which case function may fail

Of course you could have used the try-catch constructs but it still doesn't solve the second problem.

Let's consider another example for a class:

class User 
{
    private $database = null;

    public function __construct() {
        $this->database = new database('host', 'user', 'pass', 'dbname');
    }

    public function getUsers() {
        return $this->database->getAll('users');
    }
}

$user = new User();
$user->getUsers();

This code again has these problems:

• The class User has implicit dependency on the specific database. All dependencies should always be explicit not implicit. This defeats Dependency inversion principle

• If we wanted to change database credentials, we need to edit the User class which is not good; every class should be completely modular or black box. If we need to operate further on it, we should actually use its public properties and methods instead of editing it again and again. This defeats Open/closed principle

• Let's assume right now class is using MySQL as database. What if we wanted to use some other type of database ? You will have to modify it.

• The User class does not necessarily need to know about database connection, it should be confined to its own functionality only. So writing database connection code in User class doesn't make it modular. This defeats the Single responsibility principle. Think of this analogy: A cat knows how to meow and a dog knows how to woof; you cannot mix them or expect dog to say meow. Just like real world, each object of a class should be responsible for its own specific task.

• It would become harder to write unit tests for the User class because we are instantiating the database class inside its constructor so it would be impossible to write unit tests for the User class without also testing the database class.

Enter Dependency Injection!

Let's see how we can easily take care of above issues by using Dependency Injection. The Dependency Injection is nothing but injecting a dependency explicitly. Let's re-write above class:

class User 
{
    private $database = null;

    public function __construct(Database $database) {
        $this->database = $database;
    }

    public function getUsers() {
        return $this->database->getAll('users');
    }
}

$database = new Database('host', 'user', 'pass', 'dbname');
$user = new User($database);
$user->getUsers();

And there you have much better code, thanks to Dependency Injection principle. Notice that instead of hard-coding database dependency:

$this->database = new database('host', 'user', 'pass', 'dbname');

We are now injecting it into the constructor, that's it:

public function __construct(Database $database)

Notice also how we are passing database instance now:

$database = new Database('host', 'user', 'pass', 'dbname');
$user = new User($database);
$user->getUsers();

It follows Hollywood Principle, which states: "Don’t call us, we’ll call you."

Let's see if this explicit dependency injection now solves problems we mentioned above.

The class User has implicit dependency on the specific database . All dependencies should always be explicit not implicit. This defeats Dependency inversion principle

We have already made database dependency explicit by requiring it into the constructor of the User class:

public function __construct(Database $database)

Here we are taking advantage of type hinting by specifying type of object we are expecting which is Database although it wasn't necessary but it is always a good idea to type hint when you can.

If we wanted to change database credentials, we need to edit the User class which is not good; every class should be completely modular or black box. If we need to operate further on it, we should actually use its public properties and methods instead of editing it again and again. This defeats Open/closed principle

The User class now does not need to worry about how database is connected. All it expects is Database instance. We no more need to edit User class for it's dependency, we have just provided it with what it needed.

Let's assume right now class is using MySQL as database. What if we wanted to use some other type of database ? You will have to modify it.

Again, the User class doesn't need to know which type of database is used. For the Database, we could now create different adapters for different types of database and pass to User class. For example, we could create an interface that would enforce common methods for all different types of database classes that must be implement by them. For our example, we pretend that interface would enforce to have a getUser() method requirement in different types of database classes.

The User class does not necessarily need to know about database connection, it should be confined to its own functionality only. So writing database connection code in User class doesn't make it modular. This defeats the Single responsibility principle.

Of course User class now doesn't know how database was connected. It just needs a valid connected Database instance.

It would become harder to write unit tests for the User class because we are instantiating the database class inside its constructor so it would be impossible to write unit tests for the User class without also testing the database class.

If you have wrote unit tests, you know now it will be a breeze to write tests for the User class using something like Mockery or similar to create mock object for the Database.

Different Ways of Injecting Dependencies

Now that we have seen how useful Dependency Injection is, let's see different ways of injecting dependencies. There are three ways you can inject dependencies:

• Constructor Injection
• Setter Injection
• Interface Injection

Constructor Injection

We have already seen example of Constructor Injection in above example. Constructor injection is useful when:

• A dependency is required and class can't work without it. By using constructor injection. we make sure all its required dependencies are passed.

• Since constructor is called only at the time of instantiating a class, we can make sure that its dependencies cant be changed during the life time of the object.

Constructor injection suffer from one problem though:

• Since constructor has dependencies, it becomes rather difficult to extend/override it in child classes.

Setter Injection

Unlike Constructor injection which makes it required to have its dependencies passed, setter injection can be used to have optional dependencies. Let's pretend that our User class doesn't require Database instance but uses optionally for certain tasks. In this case, you would use a setter method to inject the Database into the User class something like:

class User 
{
    private $database = null;

    public function setDatabase(Database $database) {
        $this->database = $database;
    }

    public function getUsers() {
        return $this->database->getAll('users');
    }
}

$database = new Database('host', 'user', 'pass', 'dbname');
$user = new User();
$user->setDatabase($database);
$user->getUsers();

As you can see, here we have used setDatabase() setter function to inject Database dependency into the User class. If we needed some other dependency, we could have created one more setter method and injected in the similar fashion.

So Setter Injection is useful when:

• A class needs optional dependencies so it can set itself up with default values or add additional functionality it needs.

Notice that you could also inject dependency via public property for a class. So instead of using setter function $user->setDatabase($database);, you could also do $user->database = new Database(...);

Interface Injection

In this type of injection, an interface enforces the dependencies for any classes that implement it, for example:

interface someInterface {
    function getUsers(Database $database);
}

Now any class that needs to implement someInterface must provide Database dependency in their getUsers() methods.

The Problem Again

So for we have seen very contrived example of injecting dependency into a simple class but in real world applications, a class might have many dependencies. It isn't all that easy to manage all those dependencies because you need to KNOW which dependencies are required by a certain class and HOW they need to be instantiated. Let's take example of setter injection:

class User 
{
    private $database = null;

    public function setDatabase(Database $database) {
        $this->database = $database;
    }

    public function getUsers() {
        return $this->database->getAll('users');
    }
}

Since dependencies in this case are optional, we could have mistakenly written this code to get users:

$user = new User();
$user->getUsers();

Since we didn't know getUsers() method is actually dependent on Database class, this would have given error. You could have found that out only by going to code of User class and then realizing there is setDatabase() method that must be called before using the getUsers() method. Or let's assume further that before using database, we needed to set some type of configuration for the User class like:

$user = new User();
$user->setConfig($configArray);

Then again we needed to remember specific order of method calls:

$user = new User();
$user->setConfig($configArray);
$user->setDatabase($database);

So you must remember order of method calls, you can't use database if you don't setup configuration first, so you can't do:

$user = new User();
$user->setDatabase($database);
$user->setConfig($configArray);

This is example for setter injection but even with constructor injection if there are many dependencies, it becomes harder to manage all of those manually and you could easily and mistakenly create more than one instances of dependencies throughout your code which would result in high memory usage.

You might wonder dependency injection sounded like good thing to have but these problems are not worth it. Well that's not true because there is solution to all of these problems discussed next :)

Solution - Dependency Injection Container

Of course it would be difficult to manage dependencies manually; this is why you need a Dependency Injection Container. A Dependency Injection Container is something that handles dependencies for your class(es) automatically. If you have worked with Laravel or Symfony, you know that their components have dependencies on on other classes. How do they manage all of those dependencies ? Yes they use some sort of Dependency Injection Container.

There are quite some dependency injection containers out there for PHP that can be used for this purpose or you can also write your own. Each container might have bit of different syntax but they perform the same thing under the hood.

So in conclusion, you must always remove hard-coded dependencies from your code and inject them using Dependency Injection instead for its benefits and then have all the injected dependencies managed automatically for you by using some dependency injection container.

Visual Query is basic MySQL query builder and database browser app that has these basic features:

• Ability to choose different databases
• Ability to export result set to CSV and Excel
• Custom queries option
• Visual Query builder
• Query log, search facility, pagination, etc

Here is how it looks:

One can also write custom queries with syntax highlighting support as well as code prediction support:

And here is the query builder interface:

How to Use

First of all, download it from its repository. Once downloaded, edit the config.php file with database details and users login information:

// edit database settings
$config['database_host'] = 'localhost';
$config['database_user'] = 'root';
$config['database_password'] = '';
$config['database_dbname'] = 'mydb';

//////////////////////////////////////////////
// user details who can login - You can also specify more than one user
//////////////////////////////////////////////

// user 1
$config['username'][] = 'admin';
$config['password'][] = 'admin';

// user 2
$config['username'][] = 'admin2';
$config['password'][] = 'admin2';

• One-way hashing, once data is encrypted, it can't be decrypted, we chose AES (Advanced Encryption Standard)
• For same piece of text, hashing should be able to generate different encrypted text always so no two same text should sound like similar
• Code should know whether provided piece of text is already encrypted or not

I created the encryption class and did some trickery so that it always gave different encryption text for the same string. And also used some kind of prefix information that would later let the code know whether or not something is already encrypted.

The real problem for me was that by the time project had turned into huge codebase, it would have taken ages to go and modify code everywhere so that new requirement of encryption is applied everywhere. I was using DataMapper library everywhere to interact with database and model classes looked like this:

class Api_client extends DataMapper
{
    # object properties
    public $id;
    public $appid;
    public $apikey;
    public $request_uri;

    # relations
    public $has_one = array('client');

    # validation
    public $validation = array(
        'appid' => array(
            'label' => 'App ID',
            'rules' => array('required', 'trim')
        ),
        'apikey' => array(
            'label' => 'API Key',
            'rules' => array('required', 'trim')
        ),
        'request_uri' => array(
            'label' => 'Request URI',
            'rules' => array('required', 'trim')
        )
    );

    # Default to ordering by id
    public $default_order_by = array('id' => 'desc');

    # Optional - useful if a record is to be retrieved by ID eg $user = new User(1);
    public function __construct($id = null)
    {
        parent::__construct($id);
    }

    # Optional - post model initialisation code
    public function post_model_init($from_cache = false)
    {
    }
}

We can see that each model class extends the data mapper:

class Api_client extends DataMapper

This is what was a clue to me. So in order to avoid modifying lots of code in whole codebase, I knew I can only extend this data mapper and inject my functionality the way I needed.

I actually needed the ability to:

• automatically encrypt given fields in some table when saving them to database
• automatically getting the right value when reading back from database

By that I mean, instead of going everywhere in codebase and modifying code to encrypt certain fields like this:

$apiClient = new Api_client();
$apiClient->appid = Encode($appId);     // encrypt this field value
$apiClient->apikey = Encode($apikey);  // encrypt this field value
$apiClient->request_uri = $request_uri;
$apiClient->save(); // save to db

I simply wanted to leave current code as is without modifying it:

$apiClient = new Api_client();
$apiClient->appid = $appId;
$apiClient->apikey = $apikey;
$apiClient->request_uri = $request_uri;
$apiClient->save(); // save to db

In this case, I wanted data mapper to automatically encrypt the appid and apikey values for me. Now imagine I had this code placed in quite some files, it would have been time-consuming process to modify and add Encode() function calls manually everywhere.

In order to do that, I simply told data mapper which fields need to be encrypted:

class Api_client extends DataMapper
{
    ////////////////////

    // for encryption fields
    private $encryptFields = array(
       'appid',
       'apikey',
    );    
}

Now if you look at the code of data mapper, you would see it uses _to_object() function to map fields and save() function to save the info to database. So I tapped into these in my child classes and modified them a bit so that $encryptFields are auto-magically encrypted on my behalf. Since we are extending data mapper (class Api_client extends DataMapper), I modified it like this to do the encryption for me:

class Api_client extends DataMapper
{
    # object properties
    public $id;
    public $appid;
    public $apikey;
    public $request_uri;

    # relations
    public $has_one = array('client');

    # validation
    public $validation = array(
    'appid' => array('label' => 'App ID', 'rules' => array('required', 'trim')), 
    'apikey' => array('label' => 'API Key', 'rules' => array('required', 'trim')), 
    'request_uri' => array('label' => 'Request URI', 'rules' => array('required', 'trim'))
    );

    // for encryption fields
    private $encryptFields = array('appid', 'apikey');

    # Default to ordering by id
    public $default_order_by = array('id' => 'desc');

    # Optional - useful if a record is to be retrieved by ID eg $user = new User(1);
    public function __construct($id = null)
    {
        parent::__construct($id);
    }

    # Optional - post model initialisation code
    public function post_model_init($from_cache = false)
    {
    }

    // extending date modal here //
    public function _to_object($item, $row)
    {
        // Populate this object with values from first record
        foreach ($row as $key => $value) {
            if ($this->isEncryptedField($key)) {
                $item->{$key} = decodeField($value);
            } else {
                $item->{$key} = $value;
            }
        }

        foreach ($this->fields as $field) {
            if (!isset($row->{$field})) {
                $item->{$field} = null;
            }
        }

        // Force IDs to integers
        foreach ($this->_field_tracking['intval'] as $field) {
            if (isset($item->{$field})) {
                $item->{$field} = intval($item->{$field});
            }
        }

        if (!empty($this->_field_tracking['get_rules'])) {
            $item->_run_get_rules();
        }

        $item->_refresh_stored_values();

        if ($this->_instantiations) {
            foreach ($this->_instantiations as $related_field => $field_map) {
                // convert fields to a 'row' object
                $row = new stdClass();
                foreach ($field_map as $item_field => $c_field) {
                    $row->{$c_field} = $item->{$item_field};
                }

                // get the related item
                $c =& $item->_get_without_auto_populating($related_field);
                // set the values
                $c->_to_object($c, $row);

                // also set up the ->all array
                $c->all    = array();
                $c->all[0] = $c->get_clone();
            }
        }
    }

    public function save($object = '', $related_field = '')
    {
        // Temporarily store the success/failure
        $result = array();

        // Validate this objects properties
        $this->validate($object, $related_field);

        // If validation passed
        if ($this->valid) {

            // Begin auto transaction
            $this->_auto_trans_begin();

            $trans_complete_label = array();

            // Get current timestamp
            $timestamp = $this->_get_generated_timestamp();

            // Check if object has a 'created' field, and it is not already set
            if (in_array($this->created_field, $this->fields) && empty($this->{$this->created_field})) {
                $this->{$this->created_field} = $timestamp;
            }

            // SmartSave: if there are objects being saved, and they are stored
            // as in-table foreign keys, we can save them at this step.
            if (!empty($object)) {
                if (!is_array($object)) {
                    $object = array(
                        $object
                    );
                }

                $this->_save_itfk($object, $related_field);
            }

            // Convert this object to array
            $data = $this->_to_array();
            $data = $this->changeWithEncrypted($data);
            //pretty_print($data);

            if (!empty($data)) {
                if (!$this->_force_save_as_new && !empty($data['id'])) {
                    // Prepare data to send only changed fields
                    foreach ($data as $field => $value) {
                        // Unset field from data if it hasn't been changed
                        if ($this->{$field} === $this->stored->{$field}) {
                            unset($data[$field]);
                        }
                    }

                    // if there are changes, check if we need to update the update timestamp
                    if (count($data) && in_array($this->updated_field, $this->fields) && !isset($data[$this->updated_field])) {
                        // update it now
                        $data[$this->updated_field] = $this->{$this->updated_field} = $timestamp;
                    }

                    // Only go ahead with save if there is still data
                    if (!empty($data)) {
                        // Update existing record
                        $this->db->where('id', $this->id);
                        $this->db->update($this->table, $data);

                        $trans_complete_label[] = 'update';
                    }

                    // Reset validated
                    $this->_validated = false;

                    $result[] = true;
                } else {
                    // Prepare data to send only populated fields
                    foreach ($data as $field => $value) {
                        // Unset field from data
                        if (!isset($value)) {
                            unset($data[$field]);
                        }
                    }

                    // Create new record
                    $this->db->insert($this->table, $data);

                    if (!$this->_force_save_as_new) {
                        // Assign new ID
                        $this->id = $this->db->insert_id();
                    }

                    $trans_complete_label[] = 'insert';

                    // Reset validated
                    $this->_validated = false;

                    $result[] = true;
                }
            }

            $this->_refresh_stored_values();

            // Check if a relationship is being saved
            if (!empty($object)) {
                // save recursively
                $this->_save_related_recursive($object, $related_field);

                $trans_complete_label[] = 'relationships';
            }

            if (!empty($trans_complete_label)) {
                $trans_complete_label = 'save (' . implode(', ', $trans_complete_label) . ')';
            } else {
                $trans_complete_label = '-nothing done-';
            }

            $this->_auto_trans_complete($trans_complete_label);

        }

        $this->_force_save_as_new = false;

        // If no failure was recorded, return TRUE
        return (!empty($result) && !in_array(false, $result));
    }

    private function isEncryptedField($key)
    {
        if (false !== in_array($key, $this->encryptFields)) {
            return true;
        }

        return false;
    }

    private function changeWithEncrypted(array $array)
    {
        foreach ($array as $key => $value) {
            if ($this->isEncryptedField($key)) {
                if ($value !== '') {
                    $array[$key] = encodeField($value);
                } else {
                    $array[$key] = $value;
                }
            }
        }

        return $array;
    }

    private function _get_generated_timestamp()
    {
        // Get current timestamp
        $timestamp = ($this->local_time) ? date($this->timestamp_format) : gmdate($this->timestamp_format);

        // Check if unix timestamp
        return ($this->unix_timestamp) ? strtotime($timestamp) : $timestamp;
    }

}

In above class, most of the code remains same for _to_object() and save() functions as in original data mapper class but I have modified few places so that I can put encryption for needed fields.

So in conclusion, we learned how we tapped onto the data mapper class and extended it for our needs of auto-encryption of told fields. If you happen to have similar requirement or you wanted to inject your own functionality to the data mapper, you can do that through the use of _to_object() and save() functions of data mapper.

1 -NEVER FORGET VAR KEYWORD

Most of the developers know about this but yet I wanted to mention this because it may not be clear to some or newbies or people having other programming language background that come to JavaScript.

Consider the following piece of code:

function myFunc(){
    var firstName = 'sarfraz';
    lastName = 'ahmed';
}

It should be noted that in JS, variables have function-level scope which means a variable declared inside a function can not be accessed outside of it. So let’s test above two variables:

myFunc();
console.log(lastName); // ahmed
console.log(firstName); // undefined

As you will notice, we are still able to access lastName variable. The reason is that it does not have function-level scope because we forgot to put var keyword before it unlike firstName variable. Hence, lastName variable went into global scope and became part of window (while inside browser) object eg window.lastName will output the last name too.

It is therefore always required to put var keyword before variables so that they do not become part of global scope. It has following benefits:

• You save the memory and improve performance
• You don’t pollute the global scope
• You mistakenly don’t overwrite a global variable that might have the same variable name

This is a very important concept and JS developers have always been finding solutions to avoid this problem. One of the most popular solution is Singleton or Module Pattern you should check out. By the way, if you want to see other patterns also, take a look at:

Essential JavaScript Design Patterns For Beginners

2 – DECLARE VARIABLES ON TOP

Another thing that should be followed is that variables should be declared on top of each function because of what is known as JavaScript Hoisting. Here is an example:

var name = 'sarfraz';

(function(){
console.log(name); // undefined
     var name = 'nawaz';
     console.log(name); // nawaz
})();

Notice that even though name variable is outside the scope of function but on the very first line it gives back undefined rather than actual name. The reason for this is that interpreter hoists or moves variables on top of the function, here is how interpreter sees or re-arranges it:

var name = 'sarfraz';

(function(){
     var name;
     console.log(name); // undefined
     name = 'nawaz';
     console.log(name); // nawaz
})();

As can be seen, name variable has been hoisted to top and declared there and also var keyword has been stripped from it where we assigned the value of nawaz.

The same is issue is not only with variables but also function declarations but NOT with function expressions. You can learn more about the difference between function declaration and function expression here:

Named Functions Demystified

The solution to this problem is to always declare variables and function declarations on top of container function:

function myFunc(){
     var foo;
     var bar;
     var baz;

     // do something foo, bar, baz
}

The preferred and recommended syntax though that you must follow is to declare all variables in one go by separating them with a comma:

function myFunc(){
     var foo, bar, baz;

     // do something foo, bar, baz
}

3 – INITIALIZING MULTIPLE VARIABLES

Declaring variables on top is good practice but not multiple initialization. Consider:

function myFunc(){
    var lang = encoding = 'en';
}

This is a very common mistake even amongst experienced JS developers where they think they have quickly assigned two variables same scope and same value. Though value for both lang and encoding variable is some but not the scope. Try it out:

myFunc();
console.log(encoding); // en
console.log(lang); // undefined

Here again, variable encoding has gone into global scope. Since var keyword is only appears before lang variable, that is the one which gets correct functional scope. In short, you should avoid that shorthand initialization unfortunately.

4 – STARTING CURLY BRACE ON THE SAME LINE

Consider the following code block where starting curly brace { is on a new line, this works fine in most situations:

function myFunc()
{
    // some code
}

However, same convention will not yield expected results if you happen to write:

function myFunc()
{
     return
     {
         name: 'sarfraz'
     };
}

var f = myFunc();
console.log(f);

The result will be undefined because behind the scenes, interpreter puts a semicolon ; after the return keyword making it:

function myFunc()
{
     return; // <----------------
     {
         name: 'sarfraz'
     };
}

To remedy such hard-to-debug issues, it is good practice to always put starting curly brace on the same line, this would work fine though:

function myFunc() {
     return {
         name: 'sarfraz'
     };
}

var f = myFunc();
console.log(f.name); // sarfraz

And that’s a reason why Douglas Crockford in his book “JavaScript: The Good Parts“, advocates this syntax for JS:

function () {
     // some code
}

if (expression) {
     // do something
}

Go ahead and check out JavaScript Coding Style to learn more as well as naming conventions.

Notice that it is not the return keyword affected by automatic semi-colon insertion but all these too:

• var statement
• empty statement
• expression statement
• do-while statement
• continue statement
• break statement
• throw statement

Experienced JavaScript developers know pretty well about JavaScript’s automatic semi-colon insertion problem and avoid it. The benefit of above coding style however is that you avoid this problem without knowing that this problem exists just by following that coding style.

5 – USE ARRAY LITERAL INSTEAD OF NEW ARRAY()

There are two ways you can create arrays in JS:

var arr1 = new Array(); // array constructor
var arr2 = []; // array literal

Though both serve the purpose of creating arrays but there is important difference between the two.

In JS, even an array is an object. With first constructor method above, you are telling interpreter to call constructor of the Array and generate an object. The interpreter looks up into the execution context to find the constructor and once found, it calls it and creates the Array object. It seems that it has performance hit too as compared to latter array literal method. With the array literal method, interpreter just creates the array on run-time with no extra processing done.

Other than that, Array constructor is mis-guiding the way it handles its parameters. Consider:

console.log(new Array(5)); // [,,,,]
console.log(new Array('5')); // ["5"]

When one argument is passed to Array and that happens to be a number, a new array is returned with its length property equal to that number passed. The important thing to note here is that Array will be initialized from what number you specified to it, for example:

// Array constructor
var arr = new Array(2);
console.log(arr.length); // 2
console.log(arr[0]); // undefined

// Array literal
var arr = [2];
console.log(arr.length); // 1
console.log(arr[0]); // 2

So the conclusion is to always use array literal notation rather than Array constructor.

6 – USE PROTOTYPE TO SHARE ACROSS

The concept of prototypes or prototypal inheritance is rather confusing. I have seen people especially inexperienced JS developers adding class members to parent function which needs to be shared across child classes. Consider the following code:

function Person(name){
    this.name = name;
}

Now let’s assume we want to have child classes the ability to display the names some how, one of doing it is putting method directly inside Person class:

function Person(name){
     this.name = name;

     this.display = function(){
         alert(this.name);
     }
}

Other way is to use prototype:

function Person(name){
     this.name = name;
}

Person.prototype.display = function(){
     alert(this.name);
}

With both ways, all child classes will be able to use the display method but there is important difference between the two. When you attach any methods or properties via this (first way above) to a class then all instances of inheriting child classes will also have these properties or methods within them or their signature. On the other hand, when you use prototype to add members (properties and methods) to parent class, children classes will still inherit all members but it won’t be present inside their own functionality or signature, rather they will be borrowing that functionality from their parent class thereby saving memory. For this reason, later approach seems good to follow in most situations.

7 – PUT COMMA BEFORE PROPERTIES

When working with objects or arrays, it is always a good idea to put a comma before the variable or object property eg:

// jQuery - create a new div with some css
$('<div>').attr({
   "id"       : "myId"
 , "class" : "myClass"
 , "class" : "myClass"
 , "color" : "green"
 , "fontWeight" : "bold"
});

In this way, we never add an extra comma or forget one from the last property. The reason why this is good practice is that, in IE, with extra comma at the last property, we do not get expected results sometimes (ExtJS developers must have learned this). I do the same with multiple variable declarations or arguments of function. It also makes the code look pretty too as far as I see it.

8 – DON’T MIX JS AND HTML

One of the most important best practices is to always separate JS code from HTML and go unobtrusive. One would often see code like this:

<a href="#" onclick="doSomething()">Some Action</a>
<input type="button" onclick="doSomething()" value="Do Something" />
<form onsubmit="doSomething();">...

That’s a very bad practice in that it is hard to manage and maintain. HTML and JS should not be mixed ever. You could do the same thing like this:

<a href="#" id="link">Some Action</a>
<input type="button" id="button" value="Do Something" />
<form id="frm">...

<script type="text/javascript">
var link = document.getElementById('link'),
 btn = document.getElementById('button'),
 frm = document.getElementById('link');

link.onclick = function(){
 // do something
};

btn.onclick = function(){
 // do something
};

frm.onsubmit = function(){
 // validate form
};     
</script>

This way it becomes easy to manage, maintain or enhance both HTML and JavaScript.

9 – PUT SCRIPTS AT BOTTOM

Normally scripts are put in <head></head> tags but this should be avoided. The reason for this is that browser loads your scripts sequentially and by the time they are loading, nothing else is done and website load times slow down (or at least that’s how visitors will perceive it) and you see actual output only after those scripts have been loaded by the browser.

The best practice is that scripts should be put on bottom of page just before closing body tag eg </body>. This way browser will instantly display page and page load time will be better for users who view that page.

By the way, always put CSS on top in <head></head> tags because that’s something browser reads first and renders page’s layout accordingly.

Read more about this at famous Yahoo’s performance article.

I would also suggest you to use Yahoo’s YSlow or Google’s PageSpeed add-on (add-ons of Firebug) which suggest you a lot of things on how to improve the performance of the page.

10 – NEVER FORGET SEMI-COLON

Always end statements and function expressions with a semi-colon:

var name = 'some name'; // <-------------

var myFunc = function(){
// some doe

}; // <------------

This is useful when you want to compress the code (for faster load times). If at any place, semi-colon isn’t present, you won’t be able to compress the code or wouldn’t get expected results most likely code-wise. You should always, always use semi-colons.

BONUS

The good news is that you can solve most of above problems by using JSHint or JSLint code quality tool. It will tell you about best-practices and any errors that might exist in your code. Having said that, it is good to improve your JS skills and avoid the need to go to such tools.

A lambda function (also known as anonymous function) is a function that has:

1. No Name
2. Can be assigned to a variable
3. Can be passed as argument to other functions or methods of a class

In the past, this was possible with create_function like:

$multiply = create_function('$a, $b','return $a * $b;');
echo $multiply(5, 5); // 25

But it was a nuisance if you needed to write longer anonymous functions using create_function because it was difficult to write function body that way inside quotes and then escaping quotes and stuff...

PHP 5.3 introduced true support of lambda/anonymous functions similar to how you see in Javascript, so you could write above code like:

$multiply = function ($a, $b) {
    return $a * $b;
};

echo $multiply(5, 5); // 25

As can be seen, above anonymous function has no name and has been assigned to variable $multiply. You can also pass it other functions:

function countEmails($number) {
    echo 'you have ' . $number . ' emails!';
}

$multiply = function ($a, $b) {
    return $a * $b;
};

echo countEmails($multiply(2, 5)); // you have 10 emails!

You could have also written above like this if you wanted:

function countEmails($multiply, $a, $b) {
    echo 'you have ' . $multiply($a, $b) . ' emails!';
}

$multiply = function ($a, $b) {
    return $a * $b;
};

echo countEmails($multiply, 2, 5); // you have 10 emails!

And even like this:

function countEmails($multiply, $a, $b) {
    echo 'you have ' . $multiply($a, $b) . ' emails!';
}

echo countEmails(function ($a, $b) {
    return $a * $b;
}, 2, 5); // you have 10 emails!

You can also assign it to array:

$array['multiply'] = function ($a, $b) {
     return $a * $b;
};

echo $array['multiply'](2, 10); // 20

And even an object:

$obj = new StdClass();

$obj->multiply = function ($a, $b) {
     return $a * $b;
};

But caveat here is that instead of calling it like echo $obj->multiply(2, 10), you would instead need to do:

$multiply = $obj->multiply;
echo $multiply(2, 10); // 20

Now let's create little program which says Hello, World using anonymous function:

$message = 'Hello, World!';

$sayHello = function () {
    echo $message;
};

$sayHello();

Oops, it results in error:

Notice: Undefined variable: message

It means anonymous function does not have access to $message inside it. This is exactly when we need a closure to have access to that $message variable.

What is a Closure

A closure is a lambda/anonymous function that is aware of its surrounding context through the use of use keyword. It can access a variable outside of the scope where it is defined. Consider last $sayHello anonymous function and we convert it into closure through the use of use keyword and gain access to the $message variable:

$message = 'Hello, World!';

$sayHello = function () use ($message) {
    echo $message;
};

$sayHello(); // Hello, World!

Thanks to closure (use keyword), we are now able to access $message variable!

If you need to change the value of passed outside variable, you need to use reference of course:

$message = 'Hello, World!';

$sayHello = function () use (&$message) {
    echo $message;
    $message = 'Hello World Again!';
};

$sayHello(); // Hello, World!
$sayHello(); // Hello World Again!

You can also pass regular arguments to closure:

$message = 'World!';

$sayHello = function ($arg) use ($message) {
    echo $arg . ' ' . $message;
};

$sayHello('Hello'); // Hello, World!

You can also create a recursive function using closure easily, here is example of how you can create a factorial function:

$factorial = function( $n ) use ( &$factorial ) {
    if( $n == 1 ) return 1;
    return $factorial( $n - 1 ) * $n;
};

echo $factorial( 5 );

Notice that $factorial is passed by reference using & otherwise it won't work.

The difference between an anonymous function and closure is that closure has ability to access a variable outside of its scope by using the use keyword. So that is the subtle difference between an anonymous function and a closure. In fact, both are of them are instances of Closure class internally:

// anonymous function
$multiply = function ($a, $b) {
    return $a * $b;
};

$message = 'Hello, World';

// closure
$sayHello = function () use ($message) {
    echo $message;
};

var_dump ($multiply instanceof Closure); // true
var_dump ($sayHello instanceof Closure); // true

Type Hinting

We know that you can already type hint few things:

• Object
• Array
• Interface
• callable

But you can also type hint Closure as shown below:

function multiply($number, Closure $closure)
{
    return $closure($number);
}

$closure = function($x){ return $x * 2; };
echo multiply(10, $closure);

Here we have made multiply function to require type of Closure as second parameter.

Use Cases

Anonymous functions and closures can be used in variety of situations.

As Callbacks

You can use them in your custom functions as callback or some of the PHP's built-in functions such as array_map(), array_reduce(), array_filter(), array_walk(), etc. Let's take example of array_walk(). If you look at it's definition, here is how it looks:

bool array_walk ( array &$array , callable $callback [, mixed $userdata = NULL ] )

Notice the second parameter callable $callback. It means it expects something to be callable function. Anytime you see such parameter in some function definition, it means you can apply anonymous functions to it. Here is example:

$myArray = array(1, 2, 3, 4, 5);

// multiply each array value with 2    
array_walk($myArray, function(&$value, $index){
    $value *= 2;
});

print_r($myArray);

Array
(
    [0] => 2
    [1] => 4
    [2] => 6
    [3] => 8
    [4] => 10
)

In Routing

You might have seen closures being used in routing in framework like Laravel, Slim, Silex, etc:

$app = new \Slim\Slim($options);

$app->get('/', function () use ($app) {
    $app->render('home', array('content' => 'Hello, World!!!'));
});

Here $app is imported from outside scope into the scope of closure so that it can be used to render the view $app->render(...)

Accessing Private Members of a Class

We can use bind() or bindTo methods of Closure class to access private data of some class, for example:

class MyClass {
    private $variable = 'I am private variable!';
}

$closure = function() {
    return $this->variable;
};

$result = Closure::bind($closure, new MyClass(), 'MyClass');
echo $result(); // I am private variable!

There you see, we were able to get value of private variable $variable.

Similarly, it is also possible to add new behaviour to a class without actuallly modifying it direclty. Pretty cool hun ?

Lazy-loading a Class

Another ^cool^ thing you can do with closure is to lazy-load a class. For example:

class MyClass {
    public function __construct() {
        echo 'I am initialized!';
    }
}

$getMyClass = function() {
    $myClass = new MyClass();
    return $myClass;
};

If you run above code, you might expect to see I am initialized! message because one might think we are creating an instance of MyClass. That's not true though, because code inside $getMyClass anonymous function is not run until you actually call it:

$myClass = $getMyClass();

And now you would see the message I am initialized!. So this is pretty neat trick to defer some piece of code and use it only when you need it.

I started off with jQuery without knowing anything much about javascript because by the time I didn’t find any reason to learn it due to fact that javascript libraries did everything we needed putting complexities out of the way. Today I realize that I chose the wrong path, a good understanding of javascript language is crucial if you look at the reasons I have mentioned in the very beginning but it is never too late to start again, that’s exactly what I have decided, learning javascript seriously. I am not the only one who has started realizing the power and future of javascript, there are giants who have started learning it too. If you are also javascript-library-only developer, or even copy-paster programmer, you should really learn javascript seriously !

Despite design flaws and bad reputation of the language as they say and probably rightly so, javascript is popular and language of the choice for those who have gone into deeper understating of it. Javascript language does have bad parts but its good parts over-weigh its bad parts and there is always room to avoid bad parts if you know the language right and use it effectively.

Javascript turns out to be extremely tricky language, consider:

// Comparison
'' == '0';    //false
0 == '';    // true
0 =='0';    // true

// Type checking
typeof null;    // object

// Scope
function myFunc() {
  return
  {
    name: 'sarfraz'
  };
}

var f = myFunc();
console.log(f);    // undefined

I did a lot of research to find best javascript learning resources. On the journey of my exploration, I came across some of the great resources with a lot of reviews and user feedback. By now, if you made your mind to take javascript seriously, here are the best resources out there you should check out.

Books

• JavaScript: The Good Parts by Douglas Crockford
• Secrets of the JavaScript Ninja by John Resig
• Pro JavaScript Techniques by John Resig
• High Performance JavaScript by Nicholas C. Zaka
• JavaScript: The Definitive Guide by David Flanagan

Online

• Eloquent JavaScript by Marijn Haverbeke
• The JavaScript Tutorial
• JavaScript Guide MDN
• JavaScript Garden (For intermediate & advanced programmers – must read !)

Videos

• appendto.com
• Douglas Crockford’s JavaScript Video Series
• JavaScript: The Good Parts

Blogs to Subscribe

• PerfectionKills
• Dmitry A. Soshnikov
• JavaScript, JavaScript
• Adequately Good
• John Resig
• 2ality
• Notes of Maks Nemisj
• Addy Osmani
• Bonus: 33 Developers you MUST Subscribe to as a JavaScript Junkie

Tools

• Grunt (The JavaScript Task Runner)
• JSHint (JS Code Quality Tool)
• JSPerf (JS Performance Testing)
• JSUnit (JS Unit Testing)
• JSCoverage (JS Code Coverage)
• JDDoc-Toolkit (JS Documentation Tool)
• Bonus: 50 Useful JavaScript Tools

Let's see each comparison practically so we know what it means.

Interface support multiple inheritance | Abstract class does not support multiple inheritance

It means you can extend an interface with one or more (hence multiple inheritance) interfaces like:

interface Interface_A { }
interface Interface_B { }
interface Interface_C { }

interface MyInterface extends Interface_A, Interface_B, Interface_C { }

As can be seen, we are extending MyInterface with three other interfaces Interface_A, Interface_A and Interface_C.

Let's now try to extend an abstract class:

class Class_A { }

abstract class MyAbstractClass extends Class_A { }

No problem there, you CAN extend an abstract class with exactly one class but if you try to add one more:

class Class_A { }
class Class_B { }

abstract class MyAbstractClass extends Class_A, Class_B { }

This time PHP would give you strange error without telling you what you are doing wrong:

Parse error: syntax error, unexpected ',', expecting '{'

I wish PHP would have given message somewhat like (hope PHP gives smarter error messages in future versions):

Fatal Error: You cannot extend an abstract class with more than one classes

Interface does'n Contains Data Member | Abstract class contains Data Member

By data members, it means class properties or variables. So you cannot add data members to an interface:

interface MyInterface {
    public $foo = null;
}

So in an interface, only method stubs can be provided.

You can add data members to an abstract class though, this is valid code of course:

abstract class MyAbstractClass {
    public $foo = null;
}

Interface does'n contains Constructors | Abstract class contains Constructors

It sounds like this point applies to may be other languages but in PHP an interface CAN have an empty constructor shell:

interface MyInterface {
    public function __construct();
}

Like other languages, PHP shouldn't have allowed having a constructor inside an interface. But anyways, it doesn't make much sense here and should be avoided anyway.

On the other hand, an abstract class can contain constructor method:

abstract class MyAbstractClass {
    abstract public function __construct();
}

Here constructor is said to be abstract and therefore expends child classes to complement for it. However, you can also have common initialization code in constructor of an abstract class too in which case, you would need to remove the abstract keyword and provide the body for it:

abstract class MyAbstractClass {
    public function __construct() {
         // initialization code
    };
}

An interface Contains only incomplete member (signature of member) | An abstract class Contains both incomplete (abstract) and complete member

This simply means an interface can only contain method stubs not their implementation. This is pretty same as second point in the image above. This is why in methods of an interface, they don't have bodies marked with { } braces. So an interface is completely empty shell that enforces some rules that child classes must implement and that's it.

Abstract classes can have both; empty method definitions as well as full method implementation. Generally empty method stubs are prefixed with abstract keyword so that child classes must provide their implementation details. But an abstract class can also contain full method implementation inside it which are generally used for common piece of functionality that each child class may need. For example:

abstract class Animal {
    // child classes must implement this
    abstract function prey();

    public function run() {
        echo 'I am running!';
    }
}

class Dog extends Animal {
    public function prey() {
        echo 'I killed the cat !';
    }
}

class Cat extends Animal {
    public function prey() {
        echo 'I killed the rat !';
    }
}

$dog = new Dog();
$cat = new Cat();

$dog->prey(); // I killed the cat !
$cat->prey(); // I killed the rat !

$dog->run(); // I am running!
$cat->run(); // I am running!

In above code, we can see that Animal class has one abstract method called prey because each child class (animal) have their own ways of finding prey and a full implemented method called run because all animals can run, this doesn't need to be defined in each of child classes. So here run method is fully implemented and represents common data that needs to be shared across child classes.

Notice that other than common fully implemented methods inside an abstract class, you can also have common data members eg variables that need to be shared across child classes.

An interface cannot have access modifiers by default everything is assumed as public | An abstract class can contain access modifiers for the subs, functions, properties

By access modifiers, we mean ability to change scoping by using keywords like public, private and protected. We cannot use these for interfaces but we can use them for everything in abstract classes.

Members of interface can not be Static | Only Complete Member of abstract class can be Static

This is again possible in PHP (as of now with PHP 5.4) unlike other languages, so you CAN do:

interface MyInterface {
    static function foo();
}

Notice the addition of keyword static to mark it as static method.

For abstract class, you can have static members as well as those methods that are implemented in the abstract class:

abstract class MyAbstractClass {
    public static $foo = null;

    public static function foo() {}
}

But you cannot have a method to be both static and abstract, so you cannot do this, which is common across the languages:

abstract class MyAbstractClass {
    public static $foo = null;

    abstract static function foo() {} // error
}

In conclusion, interface and abstract classes are completely different from each other, you cannot interchange them or use one as alternative over the other. Interfaces are completely empty shells that expect child classes to implement everything for them. On the other hand, abstract class can not only contain common piece of information by implementing inside them but also expect child classes to fill in the remaining gaps.

PHPExecute is the fastest way to test PHP code. You write the code, hit the execute button, an ajax request is triggered and you see the output fast without page refresh. Here are some of the cool things about it:

• Very fast way to test your code
• Nice friendly interface
• Code Highlighting
• Useful PHP, system information panel
• Saving favorite code snippets
• Adding useful classes
• Easy to extend as per your needs

Screenshot

Extending PHPExecute

The good thing is that you can download (see below) it, see its source code and extend it however you like according to your needs. For example, you can add classes for testing, performance or any other purpose. One can even integrate bash commands (I am not going into details of that) to make it even more useful tool to work with.

Usage Notes

• PHPExecute uses eval function to run the code. It is strongly recommended that you should use that tool for local testing only and not on production server due to security reasons. If you do, you use it on your own risk.

• In order to save snippets, PHPExecute uses localStorage feature which is available in latest browsers (and IE9+) only and also it can be around 5MB in size. This isn’t that ideal if you are going to save a lot of snippets but you can always extend PHPExecute to add database support and save your snippets there.

• The custom functions that can be used in PHPExecute can be found in includes/functions.php file. You can add any functions in that file that you want to use directly inside PHPExecute. The custom functions can also be seen in PHP Info > User Defined Functions.

Download

Download PHPExecute at Github

I hope PHPExecute turns out to be a useful tool for you. Please do share if you add anything to it via comments so that we could know it and integrate ourselves too :)

Anyways, to speed up the code output checking process a little and rather using debug_backtrace, print_r, print, echo, var_dump, etc which you need to remove/comment again, I created a function to get output of PHP on the browser console. One could use error_log function but even that makes you go to your log file and then see the output. Of course, browser needs to support/have the console so that code result is output there. Because IE less than 8 doesn't have console, this won’t work in IE less than 8, though result won’t be affected in it. Notice that you can see console in IE=>8 by pressing F12 key and then going to Script tab where you need to make sure Console tab is selected on the right side.

Here is the function:

 /**
 * Logs messages/variables/data to browser console from within php
 *
 * @param $name: message to be shown for optional data/vars
 * @param $data: variable (scalar/mixed) arrays/objects, etc to be logged
 * @param $jsEval: whether to apply JS eval() to arrays/objects
 *
 * @return none
 * @author Sarfraz
 */
 function logConsole($name, $data = NULL, $jsEval = FALSE)
 {
      if (! $name) return false;

      $isevaled = false;
      $type = ($data || gettype($data)) ? 'Type: ' . gettype($data) : '';

      if ($jsEval && (is_array($data) || is_object($data)))
      {
           $data = 'eval(' . preg_replace('#[\s\r\n\t\0\x0B]+#', '', json_encode($data)) . ')';
           $isevaled = true;
      }
      else
      {
           $data = json_encode($data);
      }

      # sanitalize
      $data = $data ? $data : '';
      $search_array = array("#'#", '#""#', "#''#", "#\n#", "#\r\n#");
      $replace_array = array('"', '', '', '\\n', '\\n');
      $data = preg_replace($search_array,  $replace_array, $data);
      $data = ltrim(rtrim($data, '"'), '"');
      $data = $isevaled ? $data : ($data[0] === "'") ? $data : "'" . $data . "'";

$js = <<<JSCODE
\n<script>
 // fallback - to deal with IE (or browsers that don't have console)
 if (! window.console) console = {};
 console.log = console.log || function(name, data){};
 // end of fallback

 console.log('$name');
 console.log('------------------------------------------');
 console.log('$type');
 console.log($data);
 console.log('\\n');
</script>
JSCODE;

      echo $js;
 } # end logConsole

Here is an example of how to use it:

$name = 'sarfraz';
$fruits = array("banana", "apple", "strawberry", "pineaple");

$user = new stdClass;
$user->name = "Sarfraz";
$user->desig = "Sr. Software Engineer";
$user->lang = "PHP";

logConsole('$name var', $name, true);
logConsole('An array of fruits', $fruits, true);
logConsole('$user object', $user, true);

It would result in:

Although this does not prevent committing code first to see the code output if you are on facebook application development but it defintely does save some time. I have been using this function successfully so far, please let me know your ideas if any on how to improve this piece of code further.

If you don’t know about git and its benefits, there are numerous compelling reasons why it is useful, you might want to check out:

• Introduction To Git
• The Benefits of Using Git
• Modern Version Control With Git
• whygitisbetterthanx.com

The benefits of keeping all my files and projects on the cloud like Google Drive should be obvious but if you are still not sure, check out:

• Why Move to the Cloud? 10 Benefits of Cloud Computing
• The Six Key Business Benefits of Google Drive

Although there are many other cloud storage services such as Microsoft SkyDrive, Dropbox, Box, Bitcasa, etc but I chose Google Drive since it gives 10GB of free space which should be enough for my development needs. If that’s not enough for you, you can create another Gmail account and get another 10GB free. You might want to read their usage policies too if you want. You may also consider using Bitcasa which gives you unlimited space but since it is new, I can’t personally trust it as yet.

Installing Google Drive

Step 1: Create a new Gmail account to be used with Google Drive client software. Although you can use your existing account but it is good idea to create a new one used for your projects’ backup only.

Step 2: Download Google Drive from here or here. During the installation, you would be asked to specify the folder path which will be synchronized with Google Drive. Make sure that you specify a folder present on any drive other than your OS drive so that even if your system crashes or corrupts, your projects remain intact. For example, I have that folder on path D:/Google Drive/

Step 3: Once installed, run Google Drive software and specify the credentials of your newly created Gmail account.

Using Google Drive with WAMP/XAMPP

Now that we’ve setup google drive, it is time to setup document root to google drive folder and create virtual host. This would allow you to run your local projects through WAMP/XAMPP from google drive folder. The reason why we do this is that since google drive folder will be sync by google drive software, any project we put in that folder will automatically be uploaded in your google drive account.

Note: I am using XAMPP but if you are using WAMP, some settings or file paths might be different, you should consider reading its documentation.

Step 1: Inside your google drive folder, create a new folder named webroot making whole path X:\Google Drive\webroot where X represents your drive letter.

Step 2: Assuming you have specified google drive folder to be D:/Google Drive/, open httpd.conf (normally located at apache\conf folder) file in notepad or other text editor and find the line Include “conf/extra/httpd-vhosts.conf”. If there is a hash (#) before that line, remove it. Now find the line with and you should see something similar to:

<Directory />
   AllowOverride none
   Require all denied
</Directory>

Change Require all denied to Require all granted

Or if you see something like:

<Directory />
    Options FollowSymLinks
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

Change it to:

<Directory />
    ........
    Allow from all
</Directory>

Now come to bottom of the file and add:

<Directory "D:\Google Drive\webroot">
  Options Indexes MultiViews
  Order Allow,Deny
  Allow from all
</Directory>

Save the file and close it.

Step 3: Open httpd-vhosts.conf (normally located at apache\conf\extra folder) and add these lines at the end of it:

<VirtualHost 127.0.0.1:80>
    DocumentRoot "D:/Google Drive/webroot"
    ServerName gdroot.loc
    ServerAlias gdroot.loc
    ErrorLog "D:/Google Drive/webroot/logs/error.log"
    CustomLog "D:/Google Drive/webroot/logs/access.log" combined
</VirtualHost>

Save the file and close it. Notice that we have specified gdroot.loc as address which actually means google drive root (.loc signals that it is local folder) which actually maps to your google drive webroot folder eg D:/Google Drive/webroot. Notice that you could name it anything you want like mycoolwebsite.com, yourname.com, etc but of course that is local folder running from your own computer.

Step 4: Open hosts file in notepad or other text editor located at X:\Windows\System32\drivers\etc where X stands for drive letter where your OS is installed. At the end of that file add this line assuming you specified URL in above step as gdroot.loc:

127.0.0.1       gdroot.loc

Or if you also use port to access your LAMP/XAMPP URLs, specify that as well:

127.0.0.1:PORT_NUMBER_HERE       gdroot.loc

Note: If you can’t edit hosts file, you need to have file owner permission, search on Google how to do that.

Restart apache and access the new url by typing gdroot.loc in your browser. You should see screen similar to when you go to http://localhost.

Congratulations ! you have a nice workflow now. You can now put all your existing our new projects inside your new document root which was assumed to be located at D:\Google Drive\webroot and now all your projects are sync with google drive and automatically uploaded to your google account which you can access anywhere. For example, you can now access your projects at office or any other computer by installing google drive client software there and telling it sync/download your webroot folder. Your projects are now always there and backed up on the cloud :)

Let’s take cool stuff one step further by using git so that our projects file are also version-ed. If you don’t know much about git and its benefits consider reading links posted above or below in the Git Resources section.

Using Git with a Central Repository

Creating and using central repository is especially useful in a team. If you just want to keep your projects version-ed and are the only developer working on a project, the normal flow is (unless you track your project to remote host such as github):

• modify files
• commit your changes
• repeat

So essentially you can skip this section if you just want to version your project files and are only developer working on a project.

Step 1: Download msysgit from here, choose first link from there. Install it with default settings.

Step 2: Go to your google drive folder (D:\Google Drive\) and create a new folder there named central.git

Step 3: Right click on newly created folder and choose Git Bash Here and type:

git init –bare

Step 4: Create a test project folder named myproject inside your normal WAMP/XAMPP webroot/htdocs folder or google drive webroot folder mentioned above (Although you can git-manage any folder anywhere on the drive but naturally we want to git-manage projects that we run from webroot/htdocs folder).

Step 5: Right click on newly created folder, choose Git Bash Here and issue these commands one by one:

git init
git remote add central /e/Google\ Drive/central.git/
git push --all central
git push --set-upstream-to central master

Great! now we’ve setup central repository for all our git-managed projects and we can commit, push, fetch all changes from that central repository. For any new repository, you can now issue commands like:

git clone /e/Google\ Drive/central.git/
git fetch /e/Google\ Drive/central.git/
git push central
and so on

That's it.

Git Resources

• Introduction To Git
• Git for beginners: The definitive practical guide
• Easy Version Control with Git
• Pro Git Book
• Git Reference
• and more

Here are its screenshots:

How to use:

Make sure you have wamp/xampp or other stack installed. Download the app and put in www/htdocs folder and browse to that folder via browser something like http://localhost/todo. Please make sure you have sqlite extension turned on from php.ini if it isn’t already.

So go ahead and download GoodTodo to keep track of your todos.

• Web interface that allows me to create blog posts, add pages and more instead of writing blog posts manually in bunch of different text files
• Markdown editor with live preview feature so that I don't have to type Markdown syntax myself
• I needed a true blog generator instead of generic/advanced site generator

Those three things are the driving force why I created BloggerCMS. Here is complete list of features of BloggerCMS as of now:

• Graphical User Interface - manage your site via a browser
• File-based - no database required
• Truly Static - no server-side languages needed
• Portability - copy, move, backup or version control your site easily
• Integrated Markdown Editor - no need to know Markdown
• Built-in Images Manager
• Disqus Commenting System
• Search Posts Feature
• Pagination
• Responsive Layout - get started easily with the included responsive layout
• RSS Support
• Sitemap Support
• Google Analytics
• Code Highlight Support
• Tags Cloud Support
• Social Follow Section
• Categories Section
• Archives Section

To know more about BloggerCMS, head over to it's blog or see introductory post.

This is my first post on this blog hosted at awesome github pages. Previously I used to blog on wordpress here but I switched to github pages because I really wanted to have static blog with free hosting and ability to write up quick posts using Markdown syntax. In the next post, I will write about BloggerCMS, a CMS I have made that helps create static blogs. This blog has also been generated via BloggerCMS :)

On this blog, I intend to write my ideas mainly about PHP as well as other related web development technologies.

Stay tuned :)