My RSS » Planet PHP » October 7, 2009

Planet PHP

Deployment of PHP Applications

Posted: October 7th, 2009, 8:54pm MDT by Mike Willbanks
We’ve all been there, working through how we are going to be deploying the next latest and greatest solution for our company. Going through all of the rigger just to think, hey wait a second, how are we going to handle the deployment process and integrating our current solution with what we have ready for a release. Release management is always simple but yet so complex.

This all starts off with versioning, if you are not versioning your application, you have bigger problems to solve. Stop reading and get on to working with Git or SVN; If you think that it is too small for versioning, crawl back in your hole and do everyone a favor and quit the profession (not really, but really). Versioning is the main key to your deployment, you need to be able to version everything, utilize branches for major features and be fully confident in that you will not be dropping productivity in the work schedule due to the deployment in a few days.

The next item on the critical path is having an adequate bug tracker, you need to ensure that you have a solution that supports milestones or releases. These help you to match up the tickets with the release that you will be pushing out the code for. When you make a commit, ensure that it is matched to a ticket in this system as it will be very important later.

Let us start off with the version control structure, in which, we will utilize the standard structure: /trunk, /branches, /tags. In your trunk you will essentially commit anything such as bug fixes, minor features and anything that is not going to take a long time or cause issues in relation to the current code base. Branches will in turn handle your release branch, major features and/or major architectual changes. This may or may not be how you handle it, but I feel that the release branch has to come out of a separate area than the trunk and have the ability to be merged (take it or leave it).

Everything in the release branch must come from the trunk, the trunk is going to be your latest development copy and/or integration copy. You should have an environment that has continuous integration, the current copy on a machine and is controlled through your post-commit hook. In order to merge to your release branch, you should setup a script to do this automatically when it comes to release time and ensure you have a test environment.

In my current environment I do this through the svn merge-info. This process works as such:
1. Create a Hash Map of Available Revisions
2. Look at the Commit Log and Mark Associated Tickets
3. Look up Tickets from the Release
4. Merge Revisions to the Release Branch
From here the environment is updated, we also utilize items such as LiquiBase and DBDeploy to handle our database versioning depending on the system that is being utilized. This ensures that we are handing the migration to the current version of the software. By this, we have a pre-deployment file as well as a post-deployment file (depending on the system, however, it is always implemented in this way). From here we run our system through functional testing and unit testing.

If anything is to be fixed, we apply it in the trunk and follow the merging process again before our deployment to our test environment. All of these deployments are handled through svn switch for our lower environments. You will not want to do this when you are in a production environment.

Once the release has been verified to being correct by a QA staff or whomever is in charge of verifying a release, a tagging operation takes place to ensure that we have a mark at the specific location if we ever would have to go back to a prior release. This is where the operations can be a little more crazy. When deploying to a server farm, you need to ensure that you have handled the pre-deployment and post-deployment adequately in order to provide your users the best experience. If you deploy database changes that the applications code was not ready for, you have just provided your users with a failure of your system.

Apply your pre-deployment database changes and/or system changes, then follow up by processing each web server. Do an export of the changes (so that there is not revisioning information) into a release directory. Your can either move the current release to a tag (which has more performance) or create a symlink to the current release. After these changes have been made apply the post-release database or system changes.

You can automate these deployments through Phing, Ant, or a custom script. It is all up to you. I’ve done it through a custom script rather than Ant. This is due to specific requirements, you might find that different departments would rather have a s
Truncated by Planet PHP, read more at the original (another 749 bytes)
In Response to Fabien Potencier: Twig & PHP Templating

Posted: October 7th, 2009, 8:08pm MDT by Eli White

A
New approach to generate PDF using PHP with Zend Framework

Posted: October 7th, 2009, 7:36pm MDT by PHP Classes

New approach to generate PDF using PHP with Zend Framework By Jonathan Maron LiveDocx is a Zend Framework package that implements a new approach to generate PDF documents in PHP.

It combines structured data passed by a PHP script with a template created in a word processor. It is the same concept as mail merge.

The resulting document can be saved as a PDF, as well in other formats such as DOCX, DOC or RTF file.
Templating Engines in PHP

Posted: October 7th, 2009, 3:40pm MDT by Fabien Potencier
This blog post is not for the faint-hearted! Some people will strongly disagree with me and some others will probably want to kill me at the upcoming Zend Conference. And if starting an argument in the comments can help you feel better, please feel free to do so. If you want to have a more advanced discussion on this topic, vote for my talk at the Zend UnConference.

So, you think PHP is a templating engine? So did I... for a very long time. But recently, I changed my mind. Even if PHP can be used as a templating engine, the syntax is just plain ugly as a template language.

For several years now, I have been promoting web development best practices, and one of them is the separation of concerns. Of course, as the lead developer of symfony, all the projects we work on at Sensio are modeled after the MVC architecture. It certainly helps when we have big projects where many people need to work together. The developers work on the code (the Controllers and the Model) and the web designers work on the design. And templates are sometimes written by developers, but more often than not, they need to be written by web designers or by the webmasters themselves.

And a template language is something that helps you to write templates that respects this separation of concerns. A template language should find a good balance between giving enough features to ease implementing the presentation logic, and restricting the advanced features to avoid the business logic to cripple your templates.

So, when I asked a few days ago about the best and popular templating engines in PHP on Twitter, some people naturally answered "PHP" itself. I was not even surprised as that would probably have been my answer some weeks ago too.
Why PHP is not (anymore) a good template language?
Why do people still think PHP is a templating engine? Sure enough, PHP started its life as a template language, but it did not evolve like one in the recent years. If you think PHP is still a template language, can you give me just one recent change in the PHP language which enhanced PHP as a template language? I cannot think of one.

Template languages evolved a lot since 1995 and the initial release of PHP/FI:
```

 
] 
  Hey, you are using Netscape!<p>

 


  Sorry, that record does not exist<p>

  Welcome !<p>
  You have  credits left in your account.<p>
 

 
```
And as a matter of fact, PHP doesn't support many features modern template languages should have nowadays.

I will take Django as an example of a modern template language in my examples for reasons you will understand later on, and mainly because I think Django template language hits that sweet spot I talked about above.

The following sections describes the main features I want to find in a modern template language:
Concision
The PHP language is verbose. You need no less than 14 characters just to output a simple variable (and no, using the more compact <?= shortcut is not an option):
```
<?php echo $var ?>
 
```
And PHP becomes ridiculously verbose when it comes to output escaping (and yes, escaping variables coming from an unsafe source is mandatory nowadays):
```
<?php echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8') ?>
 
```
Compare with the same examples written with the Django template language:
```
{{ var }}
 
{{ var|escape }}
 
```
Template oriented syntax
This one is mostly a matter of taste, but modern template language have nice idioms to express common needs. For instance, let's say you want to iterate over an array and want to display a default text when the array is empty. That's very common, but the PHP version is not very readable:
```
Truncated by Planet PHP, read more at the original (another 19059 bytes)
	
```
Why UnCons are Important

Posted: October 7th, 2009, 6:55am MDT by Matthew Weier O'Phinney

My good friend, Keith Casey, is once again chairing Zendcon's UnCon. For those who have never attended, it's basically one or more tracks running parallel to the main conference, but with content pitched by attendees -- sometimes presented by them, other times presented by others who are knowledgeable in the field.

Why should you care? There are great sessions already selected for the conference featuring some well-known speakers from the PHP world; why would you want to either attend or present at the uncon?

Continue reading "Why UnCons are Important"
Using iPaper API to convert office documents to flash movie on the fly :)

Posted: October 7th, 2009, 5:50am MDT by Hasin Hayder

Monitoring and logging CPU Utilization of Virtual Machines in Xen

Posted: October 7th, 2009, 4:45am MDT by John Lim (PHP Everywhere - By John Lim)

Oct 6 update: Added logging of disk [d] and network [n] info.
Oct 4 update: added availability option. Now uses xentop internally.
Oct 2 update: added graphing to xenstat.pl. Now xenstat.pl detects Guest VM start/shutdown and resets itself. Number of vcpus also shown. Misc bug fixes.

You can download xenstat.pl here.

Syntax

perl xenstat.pl [$mode] [$intervalsecs=5] [$nsamples=0] [$urlToPostStats]

Quick Guide

perl xenstat.pl          -- generate cpu stats every 5 secs
perl xenstat.pl 10       -- generate cpu stats every 10 secs
perl xenstat.pl 5 2      -- generate cpu stats every 5 secs, 2 samples

perl xenstat.pl d 3      -- generate disk stats every 3 secs
perl xenstat.pl n 3      -- generate network stats every 3 secs
perl xenstat.pl a 5      -- generate cpu avail (e.g. cpu idle) stats every 5 secs

perl xenstat.pl 3 1 [server]    -- gather 3 secs cpu stats and send to URL
perl xenstat.pl d 4 1 [server]    -- gather 4 secs disk stats and send to URL
perl xenstat.pl n 5 1 [server]    -- gather 5 secs network stats and send to URL

Requires xentop from Xen 3.2 or newer xentop backported to Xen 3.1.

Usage

To use run "perl xenstat.pl" in domain 0. The following output will be generated, with a new statistic generated every 5 seconds:

[root@server ~]# perl xenstat.pl 
cpus=2
       40_falcon   2.67%    2.51 cpu hrs  in 1.96 days ( 2 vcpu,  2048 M)
       52_python   0.24%  747.57 cpu secs in 1.79 days ( 2 vcpu,  1500 M)
     54_garuda_0   0.44% 2252.32 cpu secs in 2.96 days ( 2 vcpu,   750 M)
           Dom-0   2.24%    9.24 cpu hrs  in 8.59 days ( 2 vcpu,   564 M)

                    40_falc 52_pyth 54_garu   Dom-0    Idle
2009-10-02 19:31:20     0.1     0.1    82.5    17.3     0.0 *****
2009-10-02 19:31:25     0.1     0.1    64.0     9.3    26.5 ****
2009-10-02 19:31:30     0.1     0.0    50.0    49.9     0.0 *****

In the above output, the first few lines summarise the CPUs and running domains. Then we have the statistics generated every 5 seconds. At the end of each line is a simple graph. 5 stars means 90% or over CPU utilisation, 4 stars is 70% or over, etc.

You can also define the interval to poll (in seconds), and the number of samples just like vmstat:

[root@server ~]# perl xenstat.pl 3 2
cpus=2
       40_falcon   2.67%    2.51 cpu hrs  in 1.96 days ( 2 vcpu,  2048 M)
       52_python   0.24%  748.07 cpu secs in 1.79 days ( 2 vcpu,  1500 M)
     54_garuda_0   0.44% 2258.38 cpu secs in 2.96 days ( 2 vcpu,   750 M)
           Dom-0   2.24%    9.24 cpu hrs  in 8.59 days ( 2 vcpu,   564 M)

                    40_falc 52_pyth 54_garu   Dom-0    Idle
2009-10-01 12:14:59     0.0     0.0     1.7     5.7    92.5
2009-10-01 12:15:02     0.0     0.0     0.3    10.4    89.3 *

[root@server ~]#

Logging Using REST web service

To log the CPU utilisation using the Perl script, I didn't want to install a database client in Dom-0. So I added another parameter, a URL to a web server to call with the CPU info as GET parameters. I assume wget is installed in your Dom-0.

[root@server ~]# perl xenstat.pl 10 1  [192.168.0.1] cpus=2
     54_garuda_0  0.49%  165.81 cpu sec over 3.62 days (2 vcpu,   750 M)
    59_gyrfalcon  0.62%   69.03 cpu sec over 0.80 days (2 vcpu,  2000 M)
           Dom-0  1.57%    2.15 cpu hrs over 3.62 days (2 vcpu,   564 M)


--10:46:42--  [192.168.0.1] Connecting to 192.168.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 498 [text/html]
Saving to: `STDOUT'

100%[============================================>] 498         --.-K/s   in 0s

10:46:42 (67.8 MB/s) - `-' saved [498/498]

2009-09-29 10:46:42  0.1  2.1  2.2 95.6

This will accumulate statistics for 10 seconds then send it to the above url in this format:

 [192.168.0.1]

This allows you to log the data using a REST-ful web service.

Network mode [n]

Shows total network reads and writes in KBytes or MBytes for that time period.

perl xenstat.pl n

    Network I/O (K)  52_pyth 54_garu 59_gyrf   Dom-0
 2009-10-05 19:55:08       7     979       1       3
 2009-10-05 19:55:13       6    1.2M       1       1
 2009-10-05 19:55:18       5     600       2       3

Disk IO mode [d]

Shows total reads and write requests for each domain for that time period.

 perl xenstat.pl d

  Disk I/O (Reqs)    52_pyth 54_garu 59_gyrf   Dom-0
 2009-10-05 19:51:02       4       0    1317       0
 2009-10-05 19:51:07      27       0    1140       0

Availability Option [a]

Shows CPU Availability % (which is the same as CPU Idle %) instead of CPU Utilisation %.

The problem with showing CPU Utilisatio

Truncated by Planet PHP, read more at the original (another 4478 bytes)

← October 6 (3 items) October 8 (6 items) →

My RSS » Planet PHP » October 7, 2009

Feeds

Planet PHP

Deployment of PHP Applications

Posted: October 7th, 2009, 8:54pm MDT by Mike Willbanks

In Response to Fabien Potencier: Twig & PHP Templating

Posted: October 7th, 2009, 8:08pm MDT by Eli White

New approach to generate PDF using PHP with Zend Framework

Posted: October 7th, 2009, 7:36pm MDT by PHP Classes

Templating Engines in PHP

Posted: October 7th, 2009, 3:40pm MDT by Fabien Potencier

Why UnCons are Important

Posted: October 7th, 2009, 6:55am MDT by Matthew Weier O'Phinney

Using iPaper API to convert office documents to flash movie on the fly :)

Posted: October 7th, 2009, 5:50am MDT by Hasin Hayder

Monitoring and logging CPU Utilization of Virtual Machines in Xen

Posted: October 7th, 2009, 4:45am MDT by John Lim (PHP Everywhere - By John Lim)