integrating phpdotenv ( .env ) files in CodeIgniter 3.0 using hooks

Screen Shot 2016-01-26 at 7.03.31 PM

So we all know one of the tenets of the 12 factor app is to store config in the environment. CodeIgniter allows production and development config and database files to be stored in separate directories. But they all reside inside the git repo and therefore not really safe for storing sensitive values like database connections params or auth codes.

In comes phpdotenv, a really clean way to achieve this. Laravel already implements this and it’s fairly easy to do the same in CodeIgniter as well. Here’s how :

Enable Composer

You can skip this step, if you already have Composer integrated to CI.

Composer makes PHP awesome. Although you can implement the above without composer but this method is way more elegant. The following config flag has to be turned on in your application/config/config.php file:

$config['composer_autoload'] = true;

Next create a composer.json file inside the application folder with the following contents :

After that you need to run composer install inside that directory. Here I am assuming that you have composer installed globally. The other options of course, is to download the composer.phar file (here’s how) and run php composer.phar install. But make sure not to add composer.phar to your version control. It’s not meant to be there.

I would recommend installing composer globally, here’s how you do it.

Add Hook

Now we create a pre_system hook to load phpdotenv. This is the most appropriate hook as it is called right after loading composer and before the controller. Here is what my application/config/hooks.php looks like :

And then enable hooks in application/config/config.php as it does not come enabled by default:
$config['composer_autoload'] = true;

A dirty way to do it would have been calling the same code in index.php file. But changing the core files of a framework is almost always a bad idea and makes upgrading/debugging very difficult.

Create a .env file

The hook code was configured to load the .env file from inside the applications folder. You can change that if you want.

And that’s it, you can keep separate .env on your production servers and on your dev server. The values can be accessed via either getenv() or $_ENV superglobal variables. Here is a sample .env file

Nice. So that does it. Let me know if you have something to say in the comments.

Cheers!

[typerush] the dilemma

To develop as a Product guy or to develop as a Tech guy??!

There are major differences in the approach.

A product guy will focus less on the backend technologies used, accepting a barely working prototype with acceptable design and focussing more on shipping the product out to beta testers so that things that matter can be prioritized. Look and feel will be important. Evolving usability and virality factors will be the prime focus while technology will take a back seat.

A tech guy will look to try out platform candidates before finalizing one on the basis of performance. He will try to incorporate state-of-the-art tools to make the technology stack look impressive. A few learnings on the way will be welcome and will be given dedicated bandwidth. Some delay to launch will be fine.

Is this the reason why product guys and tech guys almost always end up debating? May be.

[typerush] Upgraded framework

So in the latest change-set, I’ve upgraded our framework CodeIgniter to 3.0.4. Wasn’t hard since the custom code footprint was relatively small and nothing was changed in the core files.

Next I want to complete the multiplayer part as soon as possible. Before that some challenges, that I can see are:

  1. How would someone keep track of all the rooms that he has been in
  2. What happens when a user exits a room. Do we save the room data? If yes, then how is that accessible.
  3. Need a proper sanity process of the real time feature so that nothing is breaking.

Also in my list are some infra changes

  1. Doing JS and CSS versioning during deployment.
  2. Keeping environment related config items separate from the common config items.

There are some feature addons as well :

  1. A performance card at the end of every run.
  2. An option to mark a track as difficult or easy.
  3. The progress meter to be based on characters instead of words.
  4. Better UI

Security Measures:

  1. Applying continuous sync with server to prevent hacking of score.
  2. Setting a max value for speed, just to make sure data does not get corrupt.

[typerush] A new beginning

This is the first post of many to come in the TypeRush Series. In here, I’ll be writing on my learnings and logs of developing typerush.com as a product.

I’ll be trying to use the three step production development cycle : build, measure, learn. I’ll try to focus on things that matter instead of building a “complete” product. I’ll need help in getting feedback and am not sure at this stage how I am gonna do that.

What prompted the development of this product?
I think seeing someone keying into the computer at high speeds leaves me impressed. I wanted to be like them; to be able to type superfast. When a friend introduced me to typeracer.com during college, I was pretty much addicted. I wanted to create a better version of the same.

Who is the target audience?
At this point, typing enthusiasts is what I’ll say. Ideally, everyone who has working on a computer as part of their daily job routine. And kids and teenagers who have a gaming instinct and like to measure themselves against others.

What problem are you trying to solve?
At present it’s just a game. In the next phase, I want it to help people type better and faster.

If you want to take a pilot run at the current product, hop on to http://www.typerush.com

Type Rush