For a walkthrough of how it works and what you can do with it, read on.
In this context, configuring an application refers to setting up an Apache virtual host, granting database privileges, writing application config files, etc. Deployment refers to checking out the latest sources from version control, building the application, and installing it on all the nodes. Chef is the perfect tool to configure a web application, and in some cases it can be appropriate for deployment as well.
The infrastructure created in this tutorial is pretty basic, with the production environment running initially on a single server instance. This is a useful setup for rapid prototyping of web apps, sharing a single server among multiple applications to minimize cost and complexity. Once you’re comfortable with this basic configuration, it’s relatively simple to scale it out, separating the roles onto multiple server instances.
This is the first article in a three-part series on managing LAMP environments (Linux, Apache, MySQL, and PHP) with Chef (a configuration management tool).
The series covers using Chef to provision a development environment on a virtual machine with Vagrant and VirtualBox, and a production environment in the cloud with Amazon EC2. Prior knowledge of how to manually configure a LAMP stack is assumed–this tutorial shows how to automate the process, but doesn’t explain the configuration options in any detail.
Zend Framework 2 is getting close to release, and among the changes are new ways to handle dependency injection, and new ways to work with third-party code as modules. Rob “Akrabat” Allen has updated his iconic Getting Started with Zend Framework tutorial for ZF2, and it’s a great place to start.
After working through that tutorial, the next thing I wanted to do was figure out how to get the Doctrine 2 ORM up and running.
This article shows how to set up and use Doctrine 2 in Zend Framework 2, by extending Rob’s Getting Started tutorial to use Doctrine instead of Zend_Db.
See the complete source code for this tutorial on Github.
Updated 20 September 2014: Brought up to date with current versions of the ZF tutorial and updated Doctrine composer package name.
Updated 18 June 2012: Added support for new Doctrine config file format.
Updated 2 June 2012: Added support for ZF2 beta 4 and the new composer-based installation methods.
Web development projects often rely on third-party libraries that don’t really belong in version control alongside the application source code. For example, a PHP web application might depend on Zend Framework, Doctrine 2, and jQuery. To support a fully automated build process, I want to be able to retrieve and install the right versions of these dependencies into my application code base automatically.
There are several package management tools out there that support this kind of thing, but most seem overly complex or overly restrictive. Enter Apache Ivy, a simple and flexible dependency manager that integrates with the Apache Ant build tool. Unlike the other dependency managers I found, Ivy makes it easy to run your own repository and choose your own directory layouts and file formats.
The one drawback is that Ivy is designed to work with individual Java JAR files: archives that are typically extracted in memory by Java at runtime. I want to work with dependencies that are directories of library code, already extracted from their archives. This article shows how to set up Ivy and Ant to work together to manage such directory dependencies.
I want to make sure I get an automatic heads up the next time something like this happens. But since it’s hardly a mission critical service, I don’t want to bother with setting up Nagios or paying for anything. So I’m giving Pingdom a try.
Pingdom offers a free account that lets you monitor exactly one service, with alerts sent via email, Twitter, and mobile apps. (It can send a few SMS alerts too, but you have to pay for those eventually.) The reports look pretty nice, with some nifty details like average response times. Checks seem to be run from several locations around the US, and at least one in Europe.
This is more than enough for my needs right now. Let’s see how it works out.
Zend_Paginator is a Zend Framework component for paginating collections of data–for example, breaking a list of blog posts or search results into multiple pages. The easiest way to use Zend_Paginator is by passing it a Zend_Db_Select object, which lets it automagically modify the select query to fetch only the results for the desired page.
But designing your models to work with Zend_Paginator in this way can be messy and inelegant. It often involves either creating a Zend_Paginator instance inside your model or data mapper, or else passing a select object back out of your data mapper. Either approach seems clunky, and violates the encapsulation of your models.
A cleaner approach is to fetch a collection of your models in a custom collection class, and then pass that collection directly to Zend_Paginator. You can write your collection class in such a way that it only fetches data as needed, handling large result sets just as efficiently as passing a select object directly to Zend_Paginator.
Read on to see how. Continue reading
The staff at ProZ.com use the private social networking tool Yammer to post internal status updates. It’s an easy way to stay in the loop and know what everyone else in the company is up to.
I wrote a PHP script that posts to our Developers group on Yammer every time someone commits to our Subversion repository, to help keep on top of changes in the codebase.
This blog is built on WordPress, installed on a Micro instance of the Amazon Web Services (AWS) Elastic Compute Cloud (EC2). This post describes how to set one up yourself. It’s a nice way to get started experimenting with EC2.
AWS offers a free usage tier, providing a free Amazon EC2 Micro Instance for a year, along with free usage of S3, Elastic Block Store, Elastic Load Balancing, and AWS data transfer. (If that sounded like a jumble of nonsense, you can learn more about the AWS services here.) After the first year is up you could expect to spend around $15-$20 a month to maintain the Micro instance, depending on usage.
The whole process should take less than 30 minutes. Let’s get started.