Now, on to the more important bits, at least as far as I’m concerned.  I like Zend Framework.  I like it quite a bit.  What I don’t like is continually downloading numerous copies of it as the version numbers increase.  What I like even less is “pinning” applications to certain versions of ZF by using an SVN:External or similar technique.  What I do like is the Zend Framework PEAR channel that Ralph Schindler makes available on zfcampus.org.  This allows me to have ZF downloaded, installed, and upgraded with one command, and because it’s installed as part of PEAR, the include paths just work without extra setup.

Zend Server comes with a “fixed” version of Zend Framework (the most current package comes with 1.9.0), and my goal was to take out the version it comes with and replace it with a PEAR-installed version.  I also wanted the Zend Server web application to still understand and report the correct version information for Zend Framework.  As Zend Server’s GUI is really just another ZF application, it was fairly straight forward to do a littler reverse-engineering, and the whole process took less than 10 minutes to complete.

The steps outlined below should work on Mac and Linux.  I doubt they would have any hope of working on Windows, as it required a symlink to trick Zend Server (in the future, I’m referring to this as ZS) into using a different copy of ZF.  You could do this on Windows fairly easily still, but you’d probably need to edit one of the controllers for the ZS management GUI.  Also, the some of the commands below assume you have /usr/local/zend/bin on your PATH, which I do.  If you don’t, you may be talking to the wrong PHP, especially on a Mac, so I’d recommend doing that first.

The first step was to find out where ZS keeps its copy of ZF.  Conveniently, the GUI reports this in the “Server Info” screen as /usr/local/zend/share/ZendFramework.

Next, we need to actually install the zfcampus.org PEAR channel and download ZF.  As of this writing, the channel is serving up ZF 1.9.1, and ZS comes with 1.9.0.

1
2
3
4
5
6
7
8
9
10
11

deeporange:~ josh$ sudo pear channel-discover pear.zfcampus.org
Adding Channel "pear.zfcampus.org" succeeded
Discovery of channel "pear.zfcampus.org" succeeded
deeporange:~ josh$
 
deeporange:~ josh$ sudo pear install zfcampus/zf
downloading ZF-1.9.1.tgz ...
Starting to download ZF-1.9.1.tgz (3,272,570 bytes)
.............................done: 3,272,570 bytes
install ok: channel://pear.zfcampus.org/ZF-1.9.1
deeporange:~ josh$

Through a little casual directory snooping, we can learn that ZS has PEAR configured with a base path of /usr/local/zend/share/pear.  This means that ZF was just installed to /usr/local/zend/share/pear/Zend.  What we need to do now is get /usr/local/zend/share/ZendFramework/library/Zend (this is the path where ZS expects ZF to be) to really point to /usr/local/zend/share/pear/Zend.  On a Mac or Linux system, it’s simple enough to completely remove the ZS default ZF and create a symlink to our new install.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

deeporange:~ josh$ cd /usr/local/zend/share
deeporange:share josh$ sudo rm -fR ZendFramework/
deeporange:share josh$ mkdir ZendFramework
deeporange:share josh$ sudo mkdir ZendFramework
deeporange:share josh$ sudo mkdir ZendFramework/library
deeporange:share josh$ cd ZendFramework/library/
deeporange:library josh$ sudo ln -s /usr/local/zend/share/pear/Zend .
 
deeporange:library josh$ ls -la
total 8
drwxr-xr-x  3 root  wheel  102 Aug 15 14:21 .
drwxr-xr-x  3 root  wheel  102 Aug 15 14:21 ..
lrwxr-xr-x  1 root  wheel   31 Aug 15 14:21 Zend -> /usr/local/zend/share/pear/Zend
deeporange:library josh$

Now we can see by refreshing the Zend Server GUI screen that our Zend Framework version number is reported as 1.9.1.  An optional last step would be to modify the include path directive using the ZS admin screen to remove /usr/local/zend/share/ZendFramework, as this is merely a symlink to the PEAR base path at this point, which is already included in the include path.  Your new include path setting should look like the one below.

Now, the next time there is a new version of Zend Framework available on zfcampus.org, all you have to do to get everything upgraded is run the following command:

1

deeporange:! josh$ pear upgrade zfcampus/zf

Usage:
Pass the script a folder full of .loc files and it will create a single .gpx file for each one.

[~]$ php loc2gpx.php /path/to/.loc files

Download loc2gpx.php

Disclaimer: I’m going to try my best to keep this post from turning into a rant comparing PHP to other trendy scripting languages.  Also, If you came here with a pre-disposed opinion that PHP sucks, I’m not likely to convince you otherwise, so I’ll concede now; that’s not the point anyway.

There’s been more and more activity on the blogosphere about DSL’s lately, and I’m not buying into it (partially because some of them are well-crafted trolls).  I believe that there’s not many domain-specific languages out there, at least not “main stream” ones.  When I think DSL, I think Lego LOGO and BASH; languages that literally solve one problem.  There are many other languages available that happen to be particularly good at doing one thing or the other, however that’s not to say they couldn’t do some other thing, albeit very poorly.

There’s a mile-long spectrum of language functionality to consider here.  You have C/C++ that can be made to do damn near anything from programming your refrigerator to serving web pages.  On the short end of that spectrum are DSL’s.  So where does PHP fit into a scheme like this?  I’m going to say it sits squarely in the middle, and that’s why the internet has such a love-hate relationship with it.  PHP is good at many things, great at a few things, and terrible at a few as well.  People who don’t solve problems with PHP all day every day aren’t fully aware of it’s extensive capabilities, and have been shown most likely to start flame wars about PHP’s inferiority to (Ruby|Python|Java|C#) by an incomprehensive study I just conducted in my head.

PHP, in it’s early stages, could definitely have been considered a DSL.  It existed solely to solve one problem: the web problem.  (I’ll also argue that the folks over on 4Chan maybe creating the “web problem” as we speak.) What is the web problem?  It’s the “D” in DSL.  The domain.  How do we create web pages programmatically?  That’s the web problem, and PHP came around and started solving it.  Really damn easily.

With PHP4 and especially PHP5, times have changed.  PHP’s runtime, if you include the vast extension library, is full-featured almost to a fault these days.  Now PHP solves lots of problems, from raw-socket TCP/IP problems, to XML parsing problems, to Database problems, and more.  I’ve even heard of someone writing a software compiler in PHP (purely acadamic, of course).  So is PHP great at solving these new and more complicated problems that the Internet has brought upon us?  Nah, it’s not great at them.  But it’s pretty good, and that’s good enough, especially considering that you can tackle almost any internet-related problem without a context swith to another language (because you’re already building web pages in PHP to start with right?).

So what does PHP suck at?  Well, there are some things it just can’t, in fact probably never will, do.  PHP can’t do threads.  In fact, it’s not happy when other things that touch it are doing threads.  If you must have threads, you should probably use (Ruby|Python|Java|C#).  PHP also sucks at running for a long time.  PHP scripts just aren’t meant to run for 10 days at a time.  Somehwere along the line they’re probably going to develop a memory leak and do something nasty.  That’s OK though.  PHP wasn’t design to run for a long time or to spin up multiple threads.  And this my friends, is where the gray area comes in.  I spent the last paragraph telling you about how PHP wasn’t a DSL because it could solve all these disparate problems (or at least implying it…spoiler alert), but now we have a problem.  I just told you two of PHP’s shortcomings were language design issues.  And why were they designed that way? Well, PHP is meant to be created and torn down in the context of a web request, because PHP was meant to solve the web problem.

So no, PHP isn’t a DSL, but it used to be.  Ironically though, what makes it so popular, is that it’s really good at that one thing:  it’s damn good at creating web pages.

Up until today, I’ve been going through a tedious process of reading the svn:mergeinfo field and comparing that against the commit logs from WebSVN or Fisheye, and then using the “whiteboard” method to keep tracking of that still needs to be looked at.  To solve this problem, I wrote a quickie PHP script that will read the svn:mergeinfo property as well as another property I’ve created called “minmerge” and spit out a list of revisions to look over.  The minmerge property is basically a number I set by hand that denotes how far back in to look.  Anything lower than that revision number is assumed to have already been processed and either merged or decided not to be merged.

<?
$mergedcmd = "svnlook pg /svn/testrepo svn:mergeinfo /branches/stable";
$minmergecmd = "svnlook pg /svn/testrepo minmerge /branches/stable";
$mergemsgcmd = "";
$merged = exec($mergedcmd);
$minmerge = exec($minmergecmd);
 
$merged = str_replace("/trunk:", "", $merged);
 
$revs = explode(",", $merged);
 
echo "found " . count($revs) . " merges \n";
 
foreach ($revs as $rev)
{
	if (strpos($rev, '-'))
	{
		$bounds = explode("-", $rev);
		for ($c = $bounds[0]; $c &lt;= $bounds[1]; $c++)
		{
			$realrevs[] = $c;
		}
	} else {
		$realrevs[] = $rev;
	}
}
sort($realrevs);
 
$min = min($realrevs);
$max = max($realrevs);
echo "found " . count($realrevs) . " revisions from $min to $max\n";
echo "ignoring revs above $minmerge\n";
 
for ($c = $min; $c &lt;= $max; $c++)
{
	if (!in_array($c, $realrevs) &amp;&amp; $c &gt; $minmerge)
	{
		$unmerged[] = $c;
	}
}
 
sort($unmerged);
echo "found " . count($unmerged) . " unmerged revisions:\n";
foreach ($unmerged as $rev)
{
	echo "$rev\n";
}
?>