I also did a fresh upgrade to Ubuntu 9.10 “Karmic Koala”, which is what I was waiting on to make the switch. Went very smoothly; I stayed with nginx, except this time, instead of using the php-fcgi, I decided to try out the php-fpm route. It was a bit of a hassle, and took the better part of a day, though I got it working in the end. But that’s because it was my first time doing it. I will have a post on that soon. Basically, I installed the Ubuntu 5.2.10 packages, and then compiled php-fpm against that source, which fixed a few issues I was having with configs not getting picked up when I compiled it against the vanilla PHP source. So far so good, running with APC and memcache going.

I think I will next try to compile PHP 5.3 from source, and add PHP-FPM into it, though I feel like waiting for a package. Perhaps a project for next weekend, but definitely something to try on a virtual machine first. I was reading a few bugs that APC was a bit wonky on 5.3, so I might wait until 5.3.1, and that Suhosin is also a bit sketch. Though, it might be some good motivation to try out XCache. To be honest, I was a bit disappointed that 5.3 wasn’t included by default in 9.10. I was trying to find out when it might be, but I think it could be a while. At least this time around, I took real detailed notes on what I did, from start to finish. I’m not so afraid of compiling this time around. For instance, nginx, I compared the layout of the Ubuntu repository copy, and mimicked that with –prefix and the –sbin-path configure options. It’s just convenient having the “sudo apt-get upgrade” command. Ubuntu also made it real easy in terms of dependencies. I remember a few years ago trying to compile stuff, and it was always a nightmare. I think that’s what scared me away from it, but it was pretty painless this time around.

Other updates – phpVMS, a lot of progress, thanks to everyone for helping test, fixing alot of bugs. Made alot of core changes too, which I’ll detail in the release post – hopefully in a few weeks. Same with vaCentral, I’m trying to get them both out at the same time. But thanks to everyone testing, I’ve been able to nail a lot of bugs. It’s looking much better than it did a few weeks ago.

Anyway, I’m fried. Time for a break. And, Happy Halloween!

function process_file_upload($file, $slug, $title, $ext='PNG', $full_size=300, $small_size=100)
{
	...
}

Now that’s just a mess. Taking a hint from Javascript and jQuery, we can instead use arrays to pass in parameters, making it sane, and more importantly, readable. So it will look something like this:

$options = array (
	'file'=>$this->params['form'][$image],
	'slug'=>$folder,
	'title'=>$image,
	'ext'=>$ext,
	'full_size'=>$large_size,
	'small_size'=>$this->small_size
	);

$this->process_image_upload($options);

Alright, that sounds better. And looks much better, and I can actually understand what’s going on. But how will we work with this? As you’ve probably noticed, default parameters are gone. Here’s the code:

// Setup our options for what we want to pass
$options = array(
	'parameter1'=>'apples',
	'parameter3'=>'grapes',
	);

some_function($options);

function some_function($options)
{
	// Now these are the defaults
	$defaults = array(
		'parameter1'=>'oranges',
		'parameter2'=>'watermelons',
		'parameter3'=>'grapefruit',
		'parameter4'=>''
	);

	/* Now we merge the two arrays, except the $options
		array takes precedence */
	$options = array_merge($defaults, $options);

	/* extract() creates a variable with every key from the array
		so we can use that variable directly, this is optional */
	extract($options);

	// So now we can use the variables directly
	echo $parameter1; // This will echo "apples"
	echo $parameter2; // This will echo "watermelons"

	/* Suppose parameter4 has to be set, so we will trigger an error
		You can use throw as well if it's in a try/catch block */
	if($parameter4 == '')
	{
		trigger_error('Parameter 4 must be set to "this value" or "that value"', E_USER_WARNING);
	}

	/* Or, if you assume that the $defaults set with '' are mandatory to fill out,
		you can use this code */
	foreach($defaults as $name=>$value)
	{
		if($values == '' && $options[$name] == '' || !isset($options[$name]))
		{
			trigger_error("{$name} is blank, must have a value", E_USER_WARNING);
		}
	}
}

Now obviously this is a little more involving, but it’s not too bad, and in my opinion, it’s well worth the extra effort needed. My tipping point is functions with more than 3 parameters will get array’d options. This also requires documentation, but I don’t think that’s such a bad thing (your sanity will thank you later). You can also peek into the function’s source code to see the parameters. But this also gives you a bit more control over error messages as well, with the trigger_error, so there’s no difference from how PHP natively reports it.

Also, another advantage is adding and removing parameters. You don’t need to reorder or completely destroy things, when in the future you decide to add or remove a parameter, which makes it real handy for API type functions. Debugging and logging can also be easier, since you can dump the entire parameters array in one swoop, without having to output every single variable, one at a time. The only drawback is the lack of restrictions on a blank value, but since there is a way around it, and you’re forced to check it, IMO that’s an advantage in the end, especially since my motto is to never trust any data coming into the system, especially in an API.

server {
  ...

  location ~ \.php$ {
        include /etc/nginx/conf/fastcgi_params;
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME /var/path/to/$fastcgi_script_name;
  }
}

It’s too verbose to copy/paste into each virtual host file. Instead, you can just combine the file into the /etc/nginx/conf/fastcgi_params file. I renamed it to php_params, and this is what it’s got:

location ~ \.php(.*)$ {
  fastcgi_pass  127.0.0.1:9000;
  fastcgi_index index.php;

  fastcgi_param  QUERY_STRING       $query_string;
  fastcgi_param  REQUEST_METHOD     $request_method;
  fastcgi_param  CONTENT_TYPE       $content_type;
  fastcgi_param  CONTENT_LENGTH     $content_length;

  fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
  fastcgi_param  REQUEST_URI        $request_uri;
  fastcgi_param  DOCUMENT_URI       $document_uri;
  fastcgi_param  DOCUMENT_ROOT      $document_root;
  fastcgi_param  SERVER_PROTOCOL    $server_protocol;

  fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;

  fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
  fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

  fastcgi_param  REMOTE_ADDR        $remote_addr;
  fastcgi_param  REMOTE_PORT        $remote_port;
  fastcgi_param  SERVER_ADDR        $server_addr;
  fastcgi_param  SERVER_PORT        $server_port;
  fastcgi_param  SERVER_NAME        $server_name;

  # PHP only, required if PHP was built with --enable-force-cgi-redirect
  fastcgi_param  REDIRECT_STATUS    200;
}

Now I don’t have to change it everywhere. So, instead, now I do:

server {
  ...
  # Include the PHP Fast-CGI Params
  include /etc/nginx/conf/php_params;
}

Bam! 6 lines down to one, and much easier to administer. I like, I like.

Of course, the best resource, the official docs:
http://www.php.net

Another great (official) place:
http://talks.php.net/

The talks are by the creators of PHP. Any talks by Rasmus Lerfdorf are excellent, he stresses simplicity over complexity. He’s also the creator of PHP. Derick Rethans is also an excellent presenter, he focuses a lot on security and debugging. Definitely watch the presentations in the “Security” section of the talks, but overall, any talk in there has information you can use to your advantage.

Other sites:
http://www.smashingmagazine.com/2009/03/24/10-useful-php-tips-revisited/
http://php.about.com/od/advancedphp/Advanced_PHP.htm

Sitepoint is where I first started learning HTML and CSS many years ago:
http://www.sitepoint.com/subcat/php-tutorials

MVC tutorials (how apps should be coded; obviously there’s some contention between OO and procedural styles, but you need knowledge of both to be able to make an educated judgment about what a good balance between the two is)
http://www.phpro.org/tutorials/Model-View-Controller-MVC.html
Good to go through to understand MVC completely

CakePHP has a good introduction:
http://book.cakephp.org/view/10/Understanding-Model-View-Controller

Which brings me to CakePHP itself. It’s an excellent MVC framework; after trying out CodeIgniter, Zend, Yii, Kohana, I’ve settled on Cake.
http://cakephp.org/

SQL resources – the best is the manual. Learning the concepts behind joins is essential and important. A good tutorial:
http://www.codinghorror.com/blog/archives/000976.html

Also database design:
http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/
http://woork.blogspot.com/2008/09/10-useful-articles-about-database.html

Following that up are good ORM, which you may want to use as your database layer. CakePHP has ORM built-in, but sometimes all you need is just a DB layer.
http://www.doctrine-project.org/

For conventions, I tend to follow the CakePHP model (since that’s the framework I use the most):
http://book.cakephp.org/view/24/Model-and-Database-Conventions
http://bakery.cakephp.org/articles/view/database-design-and-cakephp
http://book.cakephp.org/view/22/CakePHP-Conventions

And then rounding it out, some general knowledge information:
http://articles.sitepoint.com/category/html
http://articles.sitepoint.com/category/javascript
http://articles.sitepoint.com/category/cssh
http://www.jquery.com

• 5,055 PIREPs submitted, with an average of 20-30 per day
• Over 22,000 flight hours recorded
• 15 airlines right now, with 705 total pilots

If that’s any indication, I think vaCentral will be a huge success. I’ve been building it on CakePHP, which has made it real easy for development. Doing some tweaks to ranking and stats, but otherwise, almost there.

In other news, I think I’ll be transferring everything over to fivedev.net, as a huge portfolio/blog type of thing. Might be better. I’m still trying to find an alternative to Wordpress, but haven’t had much luck. I have a couple of PHP articles I’ve wanted to publish, including one of writing more “portable” PHP, with stuff I learned from developing on phpVMS and other projects, but just haven’t had the time to complete it. Soon, hopefully.

Schedules:
id | departure_icao | arrival_icao

Airports
id | icao

So two ICAO columns in routes map to one same column in airports. The ICAO is a unique 4 character identifier, which is assigned to an airport. It’s quite simple actually, but took me a while to figure it it. First the Airports model:

class Airport extends AppModel
{
	public $name = 'Airport';
	public $primaryKey = 'id';
	public $actAs = array('Containable');
}

And then our Schedules model:

class Schedule extends AppModel
{
	public $name = 'Schedule';
	public $primaryKey = 'id';
	public $actsAs = array('Containable');	

	public $belongsTo = array(
		'DepartureAirport' => array(
			'className' => 'Airport',
			'foreignKey' => false,
			'conditions' => 'DepartureAirport.icao = Schedule.departure_icao',
			'fields' => '',
			'order' => ''
		),

		'ArrivalAirport' => array(
			'className' => 'Airport',
			'foreignKey' => false,
			'conditions' => 'ArrivalAirport.icao = Schedule.arrival_icao',
			'fields' => '',
			'order' => ''
		)
	);
}

So we used the $belongTo relationship, and we will define two relationships – “DepartureAirport” and “ArrivalAirport”. We also select the class we will use (which IMO, should really be called “modelName” or “useModel”, that really tripped me up, but I digress). Next, we define the conditions – we’ll use the relationship name (DepartureAirport or ArrivalAirport), and the column name, along with the column name on the current table it should join on. And that’s pretty much it. You don’t really need a relationship on the “receiving” end (the Airports table), unless you will be querying airports, and finding out what schedules go there. I’ll leave that upto you

And then for the query itself:

$this->Schedule->contain('DepartureAirport', 'ArrivalAirport');
$schedule = $this->Schedule->find('first');

// Our Airport specific data will be contained in:
$schedule['DepartureAirport']
$schedule['ArrivalAirport']

Which will now return something like (etc fields ommitted):

Array
(
	[Schedule] => Array
		(
			[schedule_id] => 4178
			[airline_id] => 2
			[code] => AEA
			[flightnum] => 6371
			[depicao] => CYUL
			[arricao] => KJFK
		)

	[DepartureAirport] => Array
		(
			[airport_id] => 597
			[iata] => YUL
			[icao] => CYUL
			[name] => Montreal / Pierre Elliot Trudeau International Airport, Quebec
			[timezone] => US/Eastern
			[location] => Montreal QC Canada
			[lat] => 45.470556
			[lng] => -73.740833
		)

	[ArrivalAirport] => Array
		(
			[airport_id] => 268
			[iata] => JFK
			[icao] => KJFK
			[name] => JFK Airport
			[timezone] => US/Eastern
			[location] => New York-Kennedy NY
			[lat] => 40.6398262
			[lng] => -73.7787443
		)

)

Note how it's using the Containable behavior; this is so it doesn't pull every relationship you've defined with that table (the schedules table above has many more relationships, but for brevity, I only pulled the relevant ones). Not specifying Containable() is REALLY expensive, especially when you don't need all those relationships to be included in every time! To speed it up even more, you should specify the actual field names to pull (the SQL * operator is expensive).

http://github.com/nshahzad/ezdb/

This will include changes to the class names, to keep it all even (ezSQL to ezDB). I’m working on APC caching right now, since that’s what I’m using on current project.

PHP 5.3 was also released today! This is an exciting release – with the addition of namespaces and __callStatic(), the static DB class will be much easier to work with (instead of replicating every function). I will be finishing up the 5.2 release first, and then subsequent releases and features, I think I will be posting to the PHP 5.3 release only, unless there’s demand to back-port it all.

I’ll also be implementing some features from CakePHP’s ORM, such as “findBy{ColumnName}({tablename})”, and other simple lookups. I’ve been using Cake alot too, and it’s a great framework.
Cheers!

• $allowed_columns parameter for quick_insert() and quick_update(). So you can pass in $_POST or $_GET, as well as a list of valid indices to use
• (optional) Exception handling with try/catch (more info)
• Set return type (object, associative array, numeric array) globally through $default_type

Also, I’m updating the wiki slowly, transferring all the useful information onto there, since it’s easy to keep everything together.

Thanks!

http://github.com/nshahzad/ezdb

I plan on creating another version (a fork I guess?) for PHP 5.3 when it hopefully launches next week. It’ll have proper namespace support. Haven’t gotten to memcache just yet (hey, been busy! , but at least there’s an easier route of distribution now.

Ouch. A shame to see it go. I’ve been going there for 6/7 years now. Good luck to them in getting it back up… they had one of the largest file libraries around.