Completed my long move today over to Linode from Slicehost. A few reasons for the switch – the main two being the price (I’m now on a Linode 560, which is 560mb of RAM, vs the 512 at Slicehost for the same price). They also give a 10% discount for pre-paying for a year, or 15% for two years. But you’re not stuck in a contract. Sweet deal there. The other reason was that Linode doesn’t force you to go on x64, so you’re not wasting memory needlessly to the OS. The box “feels” faster, probably because I have a lot more free RAM since I chose to go on 32bit. No swap usage so far (alot of room available), with identical set ups. My slice was constantly using swap. My ping times are also certainly lower. So far so good. I got to also chose the data center, over at The Planet in Dallas. The Linode control panel is also “meatier”, compared to the Slicehost manager. Linode gives you 24-hour and 30-day usage graphs, with averages and stats on CPU, network, and disk IO. Really useful information. The only downside is that the image backups at Linode are in “beta”, but doesn’t matter so much to be since I use an outside backup service anyway.

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!

Doing some reconfiguration on my webserver (nginx) to make it easier to administer. My first goal was to get rid of this nastiness:

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.

I put a list together for a friend of some good PHP resources, thought I’d stick it up here as well:

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

Been a busy few months with work, phpVMS, and vaCentral. I can’t believe my last post was in July. Time really flies!! But anyway, I’m hoping to wrap up the last two projects by the end of October. Right now, there’s 15 airlines participating in testing for vaCentral, and some impressive stats in the last two months or so I’ve been testing:

• 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.

This one took me a few to figure out. On VACentral, there are schedules, which have an arrival and departure point. These points are all stored in one table, so one row in schedule refers to multiple entries in the airports table. It looks something like (ok, not something like, but exactly):

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).

As-per Justin’s request, I’ve renamed by fork of ezSQL to ezDB. I’ve updated the github links, it’s now:

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!

Well, got github working great. Did an update today, including:

• $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!

Learning how to use github, so I created a repo for ezSQL.

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.

A huge flight sim site was hacked and destroyed this weekend  – avsim.com. An important lesson on why off-site backups are critical! They had two servers, and had a backup of A on B, and B on A. Both were taken out.

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.

Sheesh! Things have been real busy, haven’t had much time to sit down and come up with a coherent post. My next update to phpVMS keeps getting pushed back; it’s been crunch time at work.

Though I’ve been messing with a few things – I cut memory usage by about 50% in phpVMS by using __autoload(). Perhaps that can be a good next post.

But I guess the big news (maybe), is that I’m discontinuing Codon. Not that it affects anybody really except my private projects and the few projects it was used on, but I’d rather concentrate my efforts on my new love – CodeIgniter. I’m really digging it, it’s almost as it’s an exact copy of Codon, with how the models work, etc. Though there are alot of PHP4-isms, I think it’s better for me to focus some efforts on learning and modding that. Codon was a great learning project for MVC (which is what it was always meant as). I don’t think there’s any better way to learn how something works than to build it by scratch. You really get to see the ins-and-outs, the pros and cons and the dilemmas faced by doing something like that.

I’ll be porting my date/time math module over to CI soon, but also some mods I’ve been working on to introduce autoload() into CI (drastic memory improvements), and also maybe implement ezSQL into it, since ezSQL is much more lightweight than their ActiveRecord class. I’m using CI now as part of two broader projects involving phpVMS; right now it’s being used as the code behind the remote API which all the phpVMS installs do talk to. I definately like to squeeze any bit of optimizations I can find.