Where I post about code and other technical stuff, which some people may find useful.
Validation differences from CakePHP and Lithium
Validation rules are one of the changes between CakePHP and Lithium. Instead of creating the rules in the model you wish to use them with, they are now managed by a validation class. The way of calling them has also changed slightly and the way of creating custom rules has changed massively.
Assignments
To use validation rules in CakePHP you assign them to the object variable “validate” with an associative array. The key of the each array item being the name for the data field and the value being another array which can either be filled with arrays of the validation rules. With a validation rule being an associative array having the key rule and value being either a string with the name of the validation rule or an array with the fist item being a string with the validation rule and other items being arguments or the rule. Below you can see a basic example code of this.
In Lithium it’s pretty much the same with some small changes. Firstly the variable is now validates. also the defining of the validation rule no has the key ‘rule’ but is an integer 0. Also you can longer pass arguments to the validation rule in the same way, instead you can send extra options in the same way you would one of the default rules. Below is a the above code refactored into a Lithium model.
Creating
The creation of validation rules have changed massively. In CakePHP you would create a public object function named as the rule with at least one argument. The first argument is an array with contains one item which is the value of the field that is to be validated. Below is a match another field rule in CakePHP.
Below is the same rule in Lithium. Instead of it being in the model class which is awesome because it’s now decoupled from your model meaning can be used independently of your models as well as shared between models.
Options
The options are pretty much the same, however I’ve noticed some new ones and I’ve yet to find a list of all the Model options in Lithium so I figured I would just list some of them all out.
message - string - The message that the user should see if the validation rule fails.
last - Boolean - if the validation rule should be run last.
skipEmpty - Boolean - If true it means the rule is skipped when the field is empty.
required - Boolean - If true it means the field is required to pass this validation
on - String - Create/update are actions where the rule is to be implemented. Such as you’ll only want to validate some information on the creation of the row.
There is also information in the $options array that are set automatically that can contain information that can be useful.
model - String - The name of the model class.
values - Array - the contents of the $_POST array.
event - String - the type of model event, update or create.
field - String - the field name that is currently being validated.
Changing rules on fly
From time to time I need to change the validation rules that the model applies at execution. You can do this by passing an options array to the validates method with the rules in them.
The main problem I found was trying to get access to the validation rules. The reason I needed to get access to the validation rules is that the rules array passed to the validates function over writes the default rules for the model. So unless you wish to completely rewrite all the rules or not have the default rules run you need to get access to the default rules. In CakePHP it’s as simple as calling validate member from the model object. But with Lithium the model saving is done by an Entity object and not a model object. So I had to create a model object just to get the validates rules. Below you can find how I did it.
Unit Testing
Like everything code wise I want automated testing. With the validation class over the methods in the model class, unit testing validation rules became a lot easier. In fact it’s so easy it only takes a few lines of code to properly test simple validation rules, which majority are. For more advance ones obviously more advanced unit tests would be needed. Below you can find the test for the match validation rule.
Summary
While the assigning of validation rules has only changed slightly the best improvement can be found in the development and implementation of the validation rules.
Getting started with Gearman and PHP on Ubuntu
I’ve been wanting to play with Gearman for a while and just haven’t found the time. But I just found some time. So here I am playing with Gearman. So started with a fresh ubuntu install. Here’s a quick guide of how I got Gearman running tasks using pear Net_Gearman.
root@gearman:~# apt-get install php5 php-pear gearman
root@gearman:~# pear install channel://pear.php.net/Net_Gearman-0.2.3
For some reason which I can’t understand at this point the init.d gearman script won’t start up. So to start gearman job server I’ve used the follow command.
root@gearman:~# gearmand --listen=127.0.0.1 -u root -d
This isn’t exactly ideal. But currently I’m just playing so I can live with it, for now. So now to start a worker. You can see my simple code below. You have to define the constant NET_GEARMAN_JOB_PATH so it’ll look for the job classes in the correct place. If this isn’t define it’ll look at the pear location for the job.
I’ve defined a task Example, so I’ll just create that.
This just prints out what we send through. Nothing special just something I can see in terminal to see it’s working. Now it’s time for code that calls
Conclusion
This is an extremely simple example. No where near production ready code. But it’s a starting point for getting to know Gearman. Something to do is that if the worker is busy working on something with this code other jobs disappear and aren’t done.
Scale horizontally automatically with Rackspace Cloudservers
Being a geek in the era of the Cloud, I wanted to be able to have servers set up to scale automatically to suit demand. Here’s how I managed to do it with my vendor of choice Rackspace and PHP.
To start off with I needed to create a master server which I can then create images off and spawn new servers from. For the purposes of this exercise I just created a basic shell of a HTTP server with a PHP file which echos out the hostname and creates a rather big array to use memory (the easiest way to get the memory usage with a low amount of requests. For the purposes of my termination script the master server has to have a hostname of “master” so it doesn’t self terminate when it’s memory use is low.
The basic packages I needed to achieve the goal are Apache HTTPD for well the HTTPD, PHP for scripting language, curl for HTTP requests to the Rackspace API, and Monit. All can be installed on Ubuntu server with ease with the following command.
root@master:~# apt-get install apache php5 php5-cli php5-curl monit
For those who haven’t heard of Monit. Monit is a monitoring system which I used to check the memory usage of the servers and execute scripts when the memory usage hits certain points.
The contents of the Monit configuration to execute the creation and termination scripts can be found below. I set the memory usage low incase of random 60 second peaks such as being mentioned on TV or radio.
Since recreating the wheel is frowned upon for some crazy reason I’ve used a modified version of pas256’s Rackspace Cloud PHP Library. The modifications I made were based around the fact I’m using the London Rackspace API and not the US one so the endpoints had to be changed. My modified version can be found on my GitHub gists.
When the memory usage is high I wanted to create a server instance and tell my load balancer to redirect traffic to the new server. Below is how I did it. With a few configurations needed to the script to allow it to run. The following constants need setting.
API_KEY - Your Rackspace cloud API Key.
API USER - The username you use to login to the Rackspace cloud control panel.
LOADBALANCER_ID - The ID of your Loadbalancer. You can get this from the URLs used to manage it in the control panel.
FLAVOUR_ID - The size of the image you want to create, 1 being the smallest and they increment by one for the range.
With those filled in I could run the script and create servers based on my latest server image with a unique hostname so the termination script can work. The script waits for the server instance build process to finish and the server to be ready before adding it to the loadbalancer.
Once I could build them I needed to terminate them so I don’t get billed like I’m rich. The termination script needs some constants filled in just like the creation script did. (Disclaimer: If it were production code and not sample code I would have use a config file to store these in.)
The termination script works by finding the server details from the API server list based on it’s hostname. If the hostname is master then it exits the script. Once it’s found the details, it removes the server from the loadbalancer to stop new requests getting sent to the server. Then it does a graceful shutdown of apache which shuts down Apache once all the requests it’s dealing with are finished. It then runs a sleep loop checking to see if port 90 has closed yet. Once Apache has finished it’s time to delete the server.
Conclusion
Here I have a simple proof of concept to start and terminate servers using Rackspace Clould and PHP. To test the concept I used JMeter and 100 requests per second. This is a simple proof of concept and not production ready. If you have any tips or suggestions please leave a comment.
Setting up Jenkins with Lithium
After my blog post about how I set up Jenkins and Phing to build lithium apps I was asked if I could share my Jenkins set up. So I figured I might as well document the entire install. Easiest way to document the entire process is to start from fresh and document each step, so I fired up a ubuntu cloud server instance and here’s what I did to get Jenkins to successfully build my lithium app.
Step one install Jenkins, mercurial and MySQL. Jenkins to for obvious reasons. MySQL since my lithium application requires MySQL database usage. During this it’ll ask me to set my root password for MySQL. Since this is a temporary instance that won’t be about for more than an hour or so I’ve just used root. With mercurial being the version control system being used to store the code.
root@Jenkins# apt-get install mysql-server jenkins mercurial
Step two is to install php and pear. Easy enough.
root@Jenkins# apt-get install php5 php-pear php5-mysql
Step three install phing
root@Jenkins# pear channel-discover pear.phing.info root@Jenkins# pear install [--alldeps] phing/phing
Step four set up the database. Since I’m using MySQL in my app I have to create the database and the table structure. I’ve whacked all the SQL to do this in a SQL file.
root@Jenkins:~# mysql -u root -p < structure.sql
Step five configure Jenkins, to do that I just have to access the server on the port 8080 which is the default port for Jenkins.
Step six manage Jenkins, I need to install some plugins for my build since I’m using phing and mercuical.
Step seven select the phing plugin.
Step eight select mecurial plugin
Step nine install the plugins.
Step eleven wait for Jenkins to restart, this will take a minute or so.
Step twelve create a new job. I’ve just gone for the free style software project since my build is currently rather simple.
Step thirteen enter the mercurial details. I’ve blanked them out for obvious reasons. Then I needed to create a build step from the drop down and select phing and put “main” in the target input field. (I forgot to take a screenshot of this)
Step fourteen run a build, this will do the mercurial cloning for me. It fails the first time, because I’ve not included the connections.php file in mercurial due to everyone having different settings and it’s a pain when someone changes it and it breaks a bunch of peoples dev environments. (yes I know about the enviroment ability, it’s still just a pain)
Step fifthteen run another build after I’ve added the connections.php file. And see the successful build. (For some reason the circle image didn’t change to yellow/green like it should)
My current phing build file is extremely basic, since the project is in a very early stage it just runs the tests. Since Lithium has it’s own test framework I’ve created my own phing test tasks which can be found here on github. The build file I use can be found below.
Conclusion
This should be pretty much everything anyone should need to use Jenkins with Lithium. If anyone has any questions or better ways of doing things just leave a comment.
Using Phing to run Lithium tests
Since Continuous Integration is awesome and I’m going be using Lithium a lot, it was clear I needed away to run my Lithium unit tests via Jenkins. Since I use Phing for builds on Jenkins and that Lithium uses it’s own testing framework there was only one solution. Build a phing task to run Lithium tests. So after a quick hacking session I completed a quick task that allows for the running of Lithium tests and fails the build if all of them don’t pass. You can find it on github at https://github.com/icambridge/phing_li3.
Install
To install is simple, just copy the directory into the directory you have your build file in.
Build File
The build file implementation is simple, you just defined a new task with taskdef, then you can just call the task, currently it only has two parameters both of which are required.
li3Base : The location where you have the Lithium application.
tests : The namespace for the tests. It also allows for “all” to run all the tests that can be found.
Mock Request
Since the way Lithium finds the base path for the application we need to mock the Request and replace the _base() method. This will stop Lithium using the base location of Phing for the base location of the lithium app and prepending it to redirects.
Conclusion
Currently it’s a quick and rough way of running the tests, I don’t doubt as I need to do different things I’ll expand this task to allow me to achieve them. I’ll also improve the functionality of it as well.
You can download it at https://github.com/icambridge/phing_li3
