In light of the recent remote PHP exploit, I decided to update a couple servers I manage to ensure they weren't vulnerable. In each case, I had been using hand-compiled PHP builds, but decided that I'm simply too busy lately to be trying to maintain updates -- so I decided to install Zend Server. I've been using Zend Server CE on my laptop since before even any initial private betas, and have been pretty happy with it -- I only compile now when I need to test specific PHP versions.
One thing I've never been happy about, however, is that by default Zend Server exposes its administration GUI via both HTTP and HTTPS. Considering that the password gives you access to a lot of sensitive configuration, I want it to be encrypted.
My job is great: I get to play with technology and code most days. My job is also hard: how does one balance both functionality and usability in programming interfaces?
I've been working, with Ralph Schindler, on a set of proposals around the Zend Framework 2.0 MVC layer, specifically the "C", or "Controller" portion of the triad. There are a ton of requirements we're trying to juggle, from making the code approachable to newcomers all the way to making the code as extensible as possible for the radical performance tuning developers out there.
I've been using Vim for close to a decade. I've often said that "Unix is my IDE" -- because Vim is built in the Unix philosophy, allowing me to pipe input into it, out of it, and every which way I want. It fits very nicely with the Unix philosophy of doing one task well, and allowing redirection. I've found it ideal for web development in general and PHP development specifically -- in fact, I've had excellent experiences in every language I've tried my hand at developing in when using Vim.
Vim is also my chosen productivity suite. When I want to write a document, I don't go into OO.o Writer or MS Word or some other word processor; I open up a window and start typing. In most cases, I can either cut and paste my work into other tools, or pipe it to transformation tools. I worry about the content first, and the presentation later... like any good MVC application. ;-)
Like any good tool, you have to invest time in it in order to reap its benefits. My learning has, to date, fallen into three time periods:
So, this is my Vim Toolbox, 2010 edition.
In Zend Framework 2.0, we're refactoring in a number of areas in order to increase the consistency of the framework. One area we identified early is how plugins are loaded.
The word "plugins" in Zend Framework applies to a number of items:
In practically every case, we use a "short name" to name the plugin, in order to allow loading it dynamically. This allows more concise code, as well as the ability to configure the code in order to allow specifying alternate implementations.
As I write this, ZendCon begins in less than a week. I have the honor and pleasure to be speaking there again, for the sixth year running.
I had a twitter/IRC exchange yesterday with Andries Seutens and Nick Belhomme regarding applications that include widgets within their layout. During the exchange, I told Andriess not to use the
action() view helper, and both Andriess and Nick then asked how to implement widgets if they shouldn't use that helper. While I ended up having an IRC exchange with Nick to give him a general idea on how to accomplish the task, I decided a longer writeup was in order.
During the past week, I've been looking at different strategies for autoloading in Zend Framework. I've suspected for some time that our class loading strategy might be one source of performance degradation, and wanted to research some different approaches, and compare performance.
In this post, I'll outline the approaches I've tried, the benchmarking stategy I applied, and the results of benchmarking each approach.
I'm currently doing research and prototyping for autoloading alternatives in
Zend Framework 2.0. One approach
I'm looking at involves creating explicit class/file maps; these tend to be
much faster than using the
include_path, but do require some
My algorithm for generating the maps was absurdly simple:
The question was what implementation approach to use.
I'm well aware of
RecursiveDirectoryIterator, and planned to
use that. However, I also had heard of
wondered if I could tie that in somehow. In the end, I could, but the
solution was non-obvious.
Because we're in full throes of Zend Framework 2.0 development, I find myself with a variety of PHP binaries floating around my system from both the PHP 5.2 and 5.3 release series. We're at a point now where I'm wanting to test migrating applications from ZF 1.X to 2.0 to se see what works and what doesn't. But that means I need more than one PHP binary enabled on my server...
I use Zend Server on my development box; it's easy to install, and uses my native Ubuntu update manager to get updates. On Ubuntu, it installs the Debian Apache2 packages, so I get the added bonus of familiarity with the configuration structure.
I installed Zend Server some time ago, so I'm still on a PHP 5.2 mod_php binary. I have several PHP 5.3 binaries compiled and installed locally for running unit tests and sample scripts already -- so the question was how to keep my 5.2 mod_php running while simultaneously allowing the ability to run selected vhosts in 5.3?
The answer can be summed up in one acronym: FastCGI.
When I was at Symfony Live this past February, I assisted Stefan Koopmanschap in a full-day workshop on integrating Zend Framework in Symfony applications. During that workshop, Stefan demonstrated creating Symfony "tasks". These are classes that tie in to the Symfony command-line tooling -- basically allowing you to tie in to the CLI tool in order to create cronjobs, migration scripts, etc.
Of course, Zend Framework has an analogue to Symfony tasks in the Zend_Tool component's "providers". In this post, I'll demonstrate how you can create a simple provider that will return the most recent entry from an RSS or Atom feed.