Setup CodeIgniter Docker container for development

Docker

Docker is the world’s leading software container platform. Developers use Docker to eliminate “works on my machine” problems when collaborating on code with co-workers. Operators use Docker to run and manage apps side-by-side in isolated containers to get better compute density. Enterprises use Docker to build agile software delivery pipelines to ship new features faster, more securely and with confidence for both Linux and Windows Server apps. If you want to learn more about Docker head to their What is Docker section here.

CodeIgniter

CodeIgniter is a powerful PHP framework with a very small footprint, built for developers who need a simple and elegant toolkit to create full-featured web applications. If you want to learn more then head to their official website that has great documentation as well at https://codeigniter.com/

CodeIgniter on Docker

If you’re excited about using Docker for your development and you are working on a CodeIgniter (CI) based PHP project then you are lucky. It is very easy to setup CI based project with Docker. Just follow the instructions below to setup a fresh CI project with Docker.

docker-compose up -d

It will spin up two containers. One for app itself with Nginx and another for MariaDB for your DB. App container will create a directory in your project folder and install CodeIgniter in it.

Now browse http://localhost:8000 in your browser and you’ll see the CodeIgniter page. It’s that easy.

Setup Laravel with Docker containers

Docker

Docker has captured my attention lately and has been growing exponentially for last few years. Docker has revolutionized the virtualization space and has given DevOps engineers and developers a new set of tools that can ease their development as well as infrastructure resource utilization. Mostly Node.js apps have been deployed with Docker but it is not limited to only that. If you’ve been developing apps for web using PHP and Laravel framework then you are lucky that community has developed some great tools to utilize docker in their development workflow. If you are new to Docker and want to learn more about Docker then visit their website docker.com specially the section What is Docker?

Laradock

Laradock does the hard part and facilitate developers to quickly and easily setup Laravel development environment in seconds. Follow the these steps to get started.

Setup fresh environment then install Laravel inside docker

  • Create project directory. e.g. myproject
  • Create another directory within myproject directory for source that you will use commit to git repo. eg. app
  • Clone the laradock repo inside myproject folder, this will create laradock folder
git clone https://github.com/laradock/laradock.git
  • Edit the docker-compose.yml file to map to your project directory once you have it (eg. – ../app:/var/www)
  • Run the following command
docker-compose up -d nginx mysql redis beanstalkd
  • Enter the workspace
docker-compose exec workspace bash
  • cd to /var
  • Install Laravel
composer create-project laravel/laravel www
  • Open your .env file and set the following
DB_HOST=mysql
REDIS_HOST=redis
QUEUE_HOST=beanstalkd

Now open your browser and visit http://localhost

You will see running Laravel app. That was cool!

You can also connect to mysql using these settings.

Host: localhost
User: root
Password: root

If you want to add more services see the official laradock docs. It support tons of other services like memcache, pgsql etc.

Daily Use

Following are some docker related commands that you want to use on daily basis once your development environment is setup.

  • To bring up the servers to run application
docker-compose up -d nginx mysql
  • Enter workspace container to run commands like artisan, composer, phpunit, gulp etc.
docker-compose exec workspace bash

or on Windows PowerShell

docker exec -it {containerid} bash
  • List current running containers
docker ps
  • List current project containers
docker-compose ps
  • Close all running containers
docker-compose stop
  • Delete all existing containers
docker-compose down
  • View the log files
docker logs {container-name}

 

 

Code Refactoring

One reason why you should refactor your code often

Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy at the center of the system. As he wandered through the hierarchy, the consultant saw that it was rather messy. The higher level classes made certain assumptions about how the classes would work, assumptions that were embodied in inherited code. That code didn’t suit all the subclasses, however, and was overridden quite heavily. If the superclass had been modified a little, then much less overriding would have been necessary. In other places some of the intention of the superclass had not been properly understood, and behavior present in the superclass was duplicated. In yet other places several subclasses did the same thing with code that could clearly be moved up the hierarchy.

The consultant recommended to the project management that the code be looked at and cleaned up, but the project management didn’t seem enthusiastic. The code seemed to work and there were considerable schedule pressures. The managers said they would get around to it at some later point.

The consultant had also shown the programmers who had worked on the hierarchy what was
going on. The programmers were keen and saw the problem. They knew that it wasn’t really their fault; sometimes a new pair of eyes are needed to spot the problem. So the programmers spent a day or two cleaning up the hierarchy. When they were finished, the programmers had removed half the code in the hierarchy without reducing its functionality. They were pleased with the result and found that it became quicker and easier both to add new classes to the hierarchy and to use the classes in the rest of the system.

The project management was not pleased. Schedules were tight and there was a lot of work to
do. These two programmers had spent two days doing work that had done nothing to add the
many features the system had to deliver in a few months time. The old code had worked just fine. So the design was a bit more “pure” a bit more “clean.” The project had to ship code that worked, not code that would please an academic. The consultant suggested that this cleaning up be done on other central parts of the system. Such an activity might halt the project for a week or two. All this activity was devoted to making the code look better, not to making it do anything that it didn’t already do.

How do you feel about this story? Do you think the consultant was right to suggest further clean
up? Or do you follow that old engineering adage, “if it works, don’t fix it”?

Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance. The consultant was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring.

This is an excerpt from the book preface “Refactoring – by Martin Fowler”.