Thursday, August 23, 2012

Choosing To Use PHP/Kohana

There seem to be so many blog posts about using Ruby on Rails or Python/Django these days that I thought I'd voice some thoughts about how PHP/Kohana is relevant and still a strong choice.

Let's get this straight though, the languages:
  • PHP
  • Ruby
  • Python
And the frameworks I'm talking about are:
  • Kohana (PHP)
  • Ruby on Rails (Ruby)
  • Django (Python)
It can be a tremendous ear sore when people mix these up.  On the other side of the spectrum, it's also annoying to hear people rant about which languages are better than another.  It's very important to understand that the 3 of these languages can accomplish the similar goals.

If you're not familiar with Kohana you can find it here.

Kohana is still a growing framework, but it's very strong and has a lot of potential.  There have been some ORMs such as Sprig and Jelly developed by some talented developers.  It has very fast benchmarks and good code organization through an HMVC structure.

All software is built for a purpose, the goal should always be reaching that purpose while maximizing the return and minimizing the energy expenditure.  And the value I'm talking about is not always quantifiable but there is tremendous value in building a team or growing a technology. 

The choice is clearest when cost is a very prohibitive factor.  PHP developers are in the greatest quantity out there and hosting costs for Apache-PHP-MySQL services are amongst the lowest.  In addition, while some give a notion that PHP is growing dated is still amongst the higher performers.

There is something to be said about appreciating a language because of its elegance.  When it comes down to keystrokes the fewer the better.  It's true that when we're talking about development the real work that gets accomplished is physical work.  But the greatest deal of work that gets done is the architectural work.  Designing well thought out software is 80% of the battle.  When we talk about debugging problems in software the more teammates getting involved later in the development process the most costly the issue becomes.  Practicing unit testing and regression testing properly goes a long way.  And when there is a launch making repairs post launch can require migration strategies and all kinds of headache.  While debugging in inevitable, a poorly thought out project can cost ten fold in comparison to a well built project.

I've heard that there are many unskilled PHP developers in the market.  I think it's appropriate to say that using Ruby or Python can also befall unskilled developers or even skilled developers who are poor decision makers (e.g. - tunnel or narrow visioned).  The important part of building a team and therefore executing a project when you're a team lead is to spend time with each of the resources you bring into the project.  Getting on the same page with all of your team members is always key.  As with PHP, there are skilled PHP developers who can build strong object oriented code.  Also, in the same vein, PHP is also closer to C/C++.  Most C/C++ developers tend to have stronger backgrounds.

Ruby has gained loads of ground from people hearing that it is able to build applications in months rather than years, but the real benefit is the best practices followed by its developers which can translate into other languages.

Don't get me wrong though.  Ruby and Python are great languages and I fully appreciate their respective frameworks when I work with them.  Python also has a large number of highly optimized routines.

A Comparison Between Ruby, PHP and Python from Udemy

Here's a great info graphic that compares Ruby, PHP and Python from Udemy.  It makes a good comparison of the popularity of PHP versus the execution speed of Python and highlights PHP and Python as languages you should know if you're looking for work or looking to hire.

Thursday, July 26, 2012

Tracking Application Build Versions Through Git Hooks

One thing I notice that development teams often lack is unified conventions. Most people like to do things their own way. That makes it hard to build a strong development process, but when everyone can agree on flexible, robust methods of approach we can do a whole lot to make everyone's lives on the team easier.

Tracking software version is important. It becomes even more important when you need to constantly push files to production environments or coordinate versions between developers.

Here's we're doing more and more in our development process at Canvas to coordinate multiple versions for an application we're building on Kohana PHP Framework. As an aside, Kohana is a great up and rising HMVC framework for PHP. Our team has been building on it for about a year now and we're pleased with the results.

Kohana has configuration files and we're updating application/config/version.php via a git post-commit hook.

So here's the version.php file:

<?php defined('SYSPATH') or die('No direct access allowed.');
return array(
  'version' => '1.2.8',
  'last_modified' => 'Thu, 26 Jul 2012 22:59:45 EDT',

As you can see the file is pretty basic. It simply stores a version and a timestamp.

Git hooks are simply scripts which get called automatically when a specific git command is made. We've set up our script as a post-commit so that each time a commit is made our script fires off.

This Git script resides here in .git/hooks/post-commit

Here's the post-commit script

# An example hook script to prepare a packed repository for use over
# dumb transports.
# To enable this hook, rename this file to "post-commit".
exec php bin/post-commit.php

As you can see its a bash script that calls a PHP script. Here's an example of a simple version of our post-commit.php script

define('SYSPATH', getcwd());

$config_path = 'application/config/version.php';
$config = include($config_path);


function increase_minor_version($config) {
  $new_ver = '1.0.1';
  if(isset($config['version'])) {
    $old_ver = $config['version'];
    $parts = explode('.', $old_ver);
    if(isset($parts[2])) {
      $parts[2] = ((int) $parts[2]) + 1;
    $new_ver = implode('.', $parts);
  return $new_ver;

function store_config($version, $last_modified, $path) {
  $content  = "   $content .= "return array(\n";
  $content .= "  'version' => '".$version."',\n";
  $content .= "  'last_modified' => '".$last_modified."',\n";
  $content .= ");\n";

  $fh = fopen($path, 'w+');
  fwrite($fh, $content);

store_config(increase_minor_version($config), date("D, d M Y H:i:s T"), $config_path);

We're not doing much with this script here but as with our development team we can do all sorts of automation. For example, we can fire off notifications, collate version updates for our team meetings, and/or update QA bug list databases or bootstrap our application and make CLI calls in our application (which is the real reason we're firing another PHP script).

Our teams are organized so that each team member develops in separate branches. And when we coordinate our version files are consolidated and incremented accordingly.

Monday, February 06, 2012

Spotify Apps API

Spotify recently released their developer API and we already have clients asking for small apps.

Here's their API:

They have a Javascript API that communicates with the rest of their application. It seems that a lot of neat Apps can be built to leverage existing Spotify functionality and add a little more to the environment.

The apps are built through HTML5, CSS and Javascript. We noticed that they don't support WebGL but they do seem to support Flash *unofficially.

They've got a quick tutorial you can run through that is very straight forward.