I’m currently working out installation instructions for phix on Microsoft Windows before my sessions at PHPNW 11 and ZendCon in October … and I need your help, because it has been many years now since I used Windows.

If you do your PHP development using Windows on the desktop or laptop, where do you prefer to get your copy of PHP from?

… or somewhere else entirely?

Be the first to leave a comment »

The Phix Project Has A New Home

Posted by Stuart Herbert on September 23rd, 2011 in Examples, phix, Toolbox.

Phix now has a new home, as I’ve recently left Gradwell. And a new PEAR channel. And an awesome new logo thanks to Jeremy and Kerry from Magma Digital. And a roadmap on Trello.

And, if you’re using either Ubuntu or Fedora as your dev desktop/laptop, a new one-line installer that takes care of those pesky system-level dependencies that the PEAR Installer can’t help you with 🙂

How To Move To The New PEAR Channel

If you have already installed an older version of Phix from pear.gradwell.com, you’ll need to run the following commands in order to switch over to our new PEAR channel pear.phix-project.org.

$ sudo pear uninstall Gradwell/ComponentManager 
Gradwell/ComponentManagerPhpLibrary Gradwell/ComponentManagerPhpWebapp
Gradwell/ComponentManagerPhpDocbook Gradwell/ComponentManagerShared
Gradwell/ConsoleDisplayLib Gradwell/CommandLineLib
Gradwell/ValidationLib Gradwell/phix 
Gradwell/Autoloader Gradwell/ExtenderLib

Then, visit the installation instructions on phix-project.org. Try out our new one-line installers for Ubuntu or Fedora. (Got a one-line installer for another platform? Fork the website on GitHub and send me a pull request 🙂

If all goes well, you should end up with phix-0.13 installed on your computer:

$ pear list -c phix | grep phix
phix                       0.13.2  stable
phix4componentdev          0.13.2  stable

If You Have Components That Depend On Phix’s Components …

… you’ll need to edit their package.xml files:

  • Swap any references to pear.gradwell.com to pear.phix-project.org.
  • Check any <min> and <max> version numbers of any Phix components you depend on, as I’ve bumped all the version numbers.

All of Phix’s components now live in the Phix_Project namespace. You’ll need to update any classes that ‘use’ any of the Phix classes accordingly.

Be the first to leave a comment »

In my Beyond Frameworks talk, I explained how a component-based architecture can help answer some of the important (i.e. expensive!) questions you might face when creating long-lived apps that rely on a PHP framework. In this series of blog posts, I’m going to look at how to go about creating and working with components.

This is a guest post by Martin Wernståhl. Martin is a university student at Chalmers University of Technology, Sweden, currently studying the first year of Engineering Physics. He started programming at an age of 9 by writing Not-Quite-C for LEGO robots. Since then he has been programming a little bit of everything until he started with PHP around five years ago. Using CodeIgniter at first, he soon started to write libraries and hack the core of CodeIgniter until he felt that it was too limiting and resorted to starting to experiment with creating his own ORM tools (IgnitedRecord, discontinued as he no longer uses CodeIgniter and RapidDataMapper, development paused because of indecision related to syntax) and lately he has gone back to experimenting with creating a very modular PHP framework. Martin has also been a very enthusiastic supporter and tester of Phix and ComponentManager since their first releases.

If you would like to contribute a guest post about PHP components, please poke @stuherbert on Twitter.

How to Host a PEAR Channel on GitHub

GitHub has a feature called GitHub pages which they introduced about 2.5 years ago. This enables you to host static files located in a specific branch in a repository (gh-pages) on GitHub’s webserver. This can also be used to host a PEAR channel and can be very useful for smaller projects or if you don’t have the time or money to configure a specific server for PEAR. An added bonus is that the content of your PEAR channel server will be versioned by git.

For an example of a GitHub hosted PEAR channel, see the Inject Framework’s PEAR channel page.

The Repository

First, create a new repository on GitHub for your PEAR channel. You may now wonder why I wrote a new repository, this is because of the fact that it is usually better to separate your projects and the PEAR channel repository because of the difference in content, plus, the repository name will be a part of the URL. You might also not want to limit which packages you can put in the channel because of the naming of the parent repository.

A recommended name for the new repository is pear, as that will be equivalent with ${yourusername}.github.com/pear. A must is that the name is lowercase, as GitHub’s URLs are case sensitive.

For an example repository hosting a PEAR channel, see the Inject Framework’s PEAR repo on GitHub.

Create Your Repository Locally

To create the repository we are going to use Pirum. Pirum is a PEAR channel server "generator" which generates static files which can be used by any PEAR installer to install your packages.

So, create a folder for your pear repository and then place a pirum.xml file there:

 
<?xml version="1.0" encoding="UTF-8" ?>
<server>
    <name>${yourusername}.github.com/${pear_repository}</name>
    <summary>${page_title}</summary>
    <alias>${short_prefix}</alias>
    <url>http://${yourusername}.github.com/${pear_repository}</url>
</server>

yourusername and page_title are fairly self-explanatory. pear_repository is the name of the GitHub repository you will store your PEAR channel in. But what does the <alias> tag do?

The contents of the <alias> tag is the channel alias which can be used instead of the contents of <name> when installing PEAR packages after you have run pear channel-discover. An example is the InjectFramework: instead of injectframework.github.com/pear/InjectStack you write injectfw/InjectStack [1].

Then we create our new Git repository, run pirum build . to create the PEAR channel, then link our repository with GitHub and finally create and push the gh-pages branch:

 
cd my/pear/repository
git init
pirum build .
git remote add origin git@github.com:${yourusername}/${pear_repository}.git
git add *
git commit
git branch gh-pages
git checkout gh-pages
git push -u origin master
git push origin gh-pages

Now you should receive a notification from GitHub (can be sent via email too depending on your notification settings) telling you that your page build was successful [2]. It might take as long as up to 10 minutes before your pages will appear on http://${yourusername}.github.com/${pear_repository} the first time you push your changes. Following pushes should update the pages almost instantly.

Now on to see if it works as it should; if pear channel-discover http://${yourusername}.github.com/${pear_repository} does not return any errors, everything went fine. You might want to check http://${yourusername}.github.com/${pear_repository} using a browser to see if it has been uploaded first, you will get a 404 if it is not.

Creating A PEAR Package Using Phix

If you are using Phix to help maintain your project, you have an environment which already is configured for generating PEAR packages. But first you have to configure Phix so that it will generate the proper package.xml file:

First we edit the project.channel value in build.properties:

 
project.channel=${yourusername}.github.com/${pear_repository} 

Then we go on to the package.xml file, most of the everyday stuff (like adding files etc.) will be handled by Phix, but the descriptions, version history and package requirements need to be edited manually. See the PEAR package.xml documentation for more information.

Don’t forget to bump version info in build.properties and change-log information in package.xml when you are creating a new package version.

When you have got the package.xml and build.properties configured properly, use the command phing pear-package to create a PEAR package which will be placed in dist/${<packagename>}-X.Y.Z.tgz

Adding The Package To Your PEAR Channel

To add a PEAR package, you just use:

 
pirum add my/pear/repository my_pear_package-X.Y.Z.tgz
cd my/pear/repository
git commit -a -m "Added my_pear_package-X.Y.Z"
git push

Then visit ${yourusername}.github.com/${pear_repository} with your browser to see a list of all the uploaded packages.

Conclusion

In the beginning there was only pear.php.net, the only resource for PEAR packages in the world. Then other package channels arrived, and publishing your own PEAR package channel became really easy with Pirum. Now you don’t even need your own web-server to host it; you can host it on GitHub, along with the source code for your PEAR package.

Now, if we only can get some kind of PEAR channel aggregator or similar thing to avoid having to use channel-discover for every new tool we want to install…

Footnotes

  1. The channel name must match the regular expression [a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)*(/[a-zA-Z0-9-]+)*
  2. You might want to turn off email notifications for successful page builds, because the emails can easily pile up if you make many pushes.
Be the first to leave a comment »

If you’re building a web-based app, it’s always a good idea to build some instrumentation into your app. That way, you can see how your app is behaving, and how your users are interacting with your app over time.

I’m sure everyone who reads my blog is familiar with Google Analytics for tracking page hits. But what about what’s happening inside your app? Right now? Do you know?

Graphite is one way to graph the stats that you add to your app. Combine it with (say) statsd from Etsy, and adding any stats you want is easy. (Read this blog post from Etsy if you want to learn more about measuring your app, and how to add support for Statsd to your app).

Normally, you’ll probably be interested in looking at graphs that show your stats over a period of hours or days (for trend analysis), and both Graphite and Statsd are sensibly tuned for that. But what if you want to see what’s happening now, in real time? I couldn’t find any clear instructions on how to do that elsewhere, so here’s my take on how to do it. I’m assuming you’re already familiar with installing both Statsd and Graphite, and that you’ve already had both up and running successfully with their default configurations.

Making Statsd Forward Data In Real Time

By default, Etsy’s Statsd collects the data sent from your apps, and forwards it on to Graphite’s data collector (known as Carbon) every 10 seconds. For real time, we need the data forwarded on every second. To do that, edit your Statsd config, adding the ‘flushInterval’ value:

{
  graphitePort: 2003
, graphiteHost: "localhost"
, port: 8123
, flushInterval: 1000
}

A value of 1000 tells Statsd to forward data on every second.

Making Graphite Store Data At One Second Resolution

Graphite’s default / sample configuration tells it to store incoming data at 60-second resolution; that allows us to look at the total stats recorded minute by minute, but we can’t drill down to see what happens second by second. To do that, we have to tell Graphite to store the data on a second-by-second basis.

Edit /opt/graphite/conf/storage-schemas.conf, and add the following clause:

[real_time]
priority = 200
pattern = ^stats.*
retentions = 1:34560000

This tells Graphite that we want all the data received from Statsd to be kept on a second-by-second basis for 400 days … plenty long enough for any sort of comparison you might need to do.

I found that, to get Graphite to start using this new storage definition, I had to go and delete the existing data files by doing:

$ rm -rf /opt/graphite/storage/whisper/stats*

Getting Graphite To Draw Real-Time Graphs

Now all we need to do is to get Graphite showing you all the collected data in real-time. By default, Graphite will happily plot the data onto a graph, but will only generate an updated graph every 60 seconds. That’s perfect for an ops team looking for trends over hours, but it isn’t real-time.

If you’re using Memcache with Graphite, you’ll need to add this to your /opt/graphite/webapp/graphite/local_settings.py file, to tell Graphite to only cache data in Memcache for 1 second:

MEMCACHE_DURATION = 1

Is it worth caching the data at all at this resolution? Honestly, I don’t know. I guess that depends on how many people need to watch the data in real-time or not. Ideally, it would be better if Graphite dynamically set the Memcache timeout based on the data stored in the particular key, but for now, you need to either stop using Memcache, or set the cache duration to 1 second.

This now gives you graphs with 1-second resolution … now we just need to change the Graphite web-app’s auto-refresh feature to load a new graph every second. By default, it will only generate an updated graph every 60 seconds. To change this, we have to edit some of the app’s Javascript code.

  • Open the file /opt/graphite/webapp/content/js/composer_widgets.js, and locate the function ‘toggleAutoRefresh’.
  • Locate the ‘interval’ variable inside that function. Change its value from ’60’ to ‘1’.
  • Save the file, then refresh your web browser page.

Et voila. If you switch on auto refresh, you should now be able to see your app’s data being plotted second by second, giving you a real-time view of what your app is doing.

Be the first to leave a comment »

Steps For Building A Test VM

Posted by Stuart Herbert on September 18th, 2011 in phix, Toolbox.

Using virtual machines for testing software is great. I can try out anything I want, and there’s never any risk of trashing my main dev machine (which avoids hours of lost coding time!). I’ve been using virtual machines since the 1990’s, and frankly I couldn’t develop without them. (I’ve also got a lot of experience running a private cloud of VMs for one of the UK’s fastest-growing tech companies, but that’s a topic for another day or maybe a conversation over a nice whisky at one of the upcoming conferences 😉

Right now, I’m using them to test phix out on multiple Linux distros before release. It’s a sad fact of life that all of the major distros think they can create a better PHP than the folks upstream at PHP.net intended, and that unfortunately means that a default install of PHP on Ubuntu can’t always run the same PHP code as a default install of PHP on Fedora. I found this out the hard way with an early release of phix; now, every release gets tested in a small but growing library of test VMs before I push it up to my public website.

But the best thing of all? You can backup a VM (normally by creating a snapshot), and then rollback to your snapshot in future – resetting your test environment to a known state before you test again. Perfect for this weekend’s task, which has been documenting and double-checking the steps needed to install phix on Linux dev desktops.

I thought it would be useful (to jog my own memory when the Linux distros release their next versions), to write up the steps that I do when I create a new test VM.

  • Install Linux distro from latest available ISO image.
  • Run the software upgrade tools to make sure the system is fully patched.
  • Disable SELinux if it is enabled.
  • Make sure gcc and the Linux kernel headers are installed on the system.
  • Install VMWare tools (for VMWare Workstation / Fusion) or VirtualBox Addons (for VirtualBox OSE).
  • Use Firefox to install Google Chrome.
  • Install some useful dev tools: curl and git

At this point, I shut down the virtual machine, and take a snapshot – before PHP is installed. That’s because I need to make sure that phix’s upcoming installer script does the right thing when there is no PHP. If you’re building your own test VMs, you’ll probably want to get Apache, PHP and MySQL installed and your app’s vhosts serving static pages before you snapshot.

What else would you do to a test VM to make it ready to run your tests?

Be the first to leave a comment »

This Month

September 2011
M T W T F S S
« Aug   Oct »
 1234
567891011
12131415161718
19202122232425
2627282930