OS X Lion comes with most of the tools you would need to do "MAMP" (Mac OS X, Apache, MySQL/MariaDB, PHP) development, as outlined in my previous posts once you add a database. So then why would you want to use MacPorts? Setting your development environment up in MacPorts isolates the binaries, libraries, and configuration files, completely separate from the existing OS X install (with the exception of startup scripts). You can also tweak the configuration files on your own, apply your own patches, and apply updates that MacPorts may get before Apple pushes them. It will take more time because you'll be compiling everything, but you have all of the control. Read on for how to get things set up.

On Snow Leopard, you can install drush without using sudo. A dependency for installing drush is downloading a Pear library. The following example should allow you to be able to use the following commands to install drush to /usr/local/drush with a symlink in /usr/local/bin/drush, but it fails on the 'pear download' step, even though it's writing to a user-writeable directory. Read on the figure out how to fix this annoying problem.

I had previously written a post on one method of upgrading PHP from 5.1 to 5.2 on CentOS and Red Hat servers by creating new RPMs. Since then, I have found a much better way to create PHP 5.2.17 (or newer) RPMs to easily upgrade (and later remove, if you want) the older version available by default. I'll presume you have no prior experience building PHP RPMs.

For anyone else who's having trouble with include path errors when trying to run PHP-based bundle commands in Textmate like this one:

PHP Warning: require(/lib/beautify.php): failed to open stream: No such file or directory in /private/tmp/temp_textmate.4tD2ED on line 19

It looks like the problem has to do with php.ini configuration settings that ship with MacPorts (may be the production sample ini file, in particular). In order to environment variables to populate the $_ENV global that Textmate uses for settings, etc, be sure you've got the letter "E" at the front of the "variables_order" setting value, like this:

variables_order = "EGPCS"

Reluctant hat-tip to an article on Experts Exchange for this one.

Today I learned:

1. That there's always more tricks in the PHP bag
2. That the max() command will return the element with the highest-value key when returned an associative array. So, given $a = array(1 => "red", 5 => "green", 10 => "blue");, max($a) will return "blue".

An updated, easier method can be found here.

Here at EchoDitto, most of our servers are running CentOS Linux, which is a 100% binary-compatible version of the industry standard Red Hat Enterprise Linux (RHEL) without any of the fees. The problem with RHEL/CentOS is that they shipped with PHP 5.1.6, and as of this writing PHP is at 5.2.9. That's not a big deal, being a minor point revision behind, until you come across an application or module that needs a minimum of version 5.2. The last thing I want to do is install packages from a third-party or build it from source and risk breaking other packages. So what's the answer? Building it from the source rpm. There's no better way to keep the system free of third-party packages but also up to date.

Every 6 months or so I take a stab at setting up line-level, breakpoint style debugging for PHP. In the past I've been able to get the debugger installed, but the lack of a decent interface to use in setting breakpoints and watches has limited the value of a debugger (one thing that I have found helpful is XDebug's profiling feature that lists all function calls in a nested format along with performance timing). The recent announcement of a new XDebug client for OS X got me back on that track, and while I wasn't able to get MacGDBP working as I wanted, it did lead me to re-evaluate the newest Eclipse offering for PHP coders: PDT. PDT has come a long way, and the combination of a robust IDE, nimble 'jumpt to' shortcuts and killer debugger integration are more than I can pass up. Here's how I got everything working on a Mac OS X 10.5 box.

Much of what follows was made possible by and incorporates instructions from these very good tutorials:

I'm a little shocked to see that we haven't talked about Yahoo Pipes around these parts. It's an awfully cool service, and one that we use around the office for various non-mission-critical functions — getting larger photos from a Flickr stream for display on the monitors in the lobby, for one thing.

For those unaware, Pipes lets you mix, translate, annotate and otherwise alchemically modify feeds of all sorts. Want to add a (possibly) relevant photo to each entry on your blog? Or only get posts from a particular author on a group blog? Or get filtered Craiglist real estate listings translated into German and sent to your mobile phone? Pipes can do all of this, and does so via a terminally-slick GUI.

But recently a friend tipped me off to Pipes' most significant capability. The folks at Yahoo! have unveiled the Holy Grail of feed-manipulation components: a JSON-powered interface to external web services. If Pipes doesn't offer some functionality you need, you can now write a web service that does and connect it to the system.

Their example code is in Java, but it didn't take much effort for me to get one working in PHP. Just install the JSON PECL Package and use code like the following:

Here's something I recently presented at the DC Drupal Meetup:

You've already heard us prattle on about Hey!Watch — it's a great video transcoding service that we've gotten in the habit of using for several of our clients. As much fun as wrestling with ffmpeg is, sometimes it's more appealing to just bit then bullet, pay a dime per transcode and not have to worry about keeping your codecs up to date.

They offer some neat add-on features, too, like direct uploading of transcoded videos to your Amazon S3 account. Even more tantalizingly, there's this: a method for allowing your users to upload directly to Hey!Watch's servers, complete with fancy-pants AJAX progress indicator. There's no need to spend your server's bandwidth and CPU on videos at all — you can stick to running Drupal on your system, outsourcing all the heavy lifting. You can send along your own arbitrary variables with the video submission, then receive them back via a ping that Hey!Watch sends once transcoding is complete (allowing you to keep track of who uploaded what video). It's pretty slick.

But interested Drupal developers will click through to the Hey!Watch code and despair. First, the AJAX is written with Prototype, which won't play nicely with Drupal's preferred jQuery library. Sure, it'd be possible to rewrite it in jQuery — but I'd really rather not.

Second and more damningly (and unsurprisingly), the form that uploads to Hey!Watch needs to stand on its own. You won't be able to nest it in a Drupal form — Drupal understandably doesn't like nested forms.

You've probably heard of Asterisk before. It's one of those buzzed-about open source projects that keeps popping up on O'Reilly and Slashdot. Take our word for it: it's fun stuff. At EchoDitto we run our office phone system on it, have built client applications around it, and even made a version of Tetris for our lobby monitors that runs on it (more on that later).

But getting into Asterisk can seem more intimidating than it really is. There's plenty of documentation around, but a lot of it seems to assume that the reader has just come home from his or her job managing AT&T's fiberoptic backbone and is now hoping to screw around with some open-source fun. In other words, it's written for an audience of VoIP engineers.

Well, none of us are VoIP engineers. If you're like us, you're a general technologist who builds stuff on the web, knows that in five years your toaster will have Ruby bindings, and realizes that There Is No Spoon. You've used Skype and heard of Vonage, but you don't know much about VoIP besides that. And now you'd like to use Asterisk to recreate the final scene in The Lawnmower Man (the director's cut) — or maybe just have your website talk to people over the phone.

We can do that! In fact, it's probably easier than you think. In this post I'll outline how to get up and running with Asterisk, how to connect it to the Plain Ol' Telephone System (POTS) and how to connect it to your programs. From there it's up to you.