If you’re not familiar with design patterns, I highly recommend reading the seminal work by the Gang of Four: Design Patterns: Elements of Reusable Object-Oriented Software. Its a bit dry but an excellent read. I remember when Joshua Storck recommended the book to me many years ago; it opened my eyes to a higher level of programming and helped me grow from a task implementer to a software designer.

Patterns are helpful for structuring thought around problems and forming elegant solutions. However, there are a few things to keep in mind: Patterns have consequences, and patterns are not best-practices. Programmers must still apply thought. Terry Chay describes this in his article, Challenges and Choices.

I just came across an article by Amy Hoy in which she describes the dangers of over relying on patterns. She’s spot on:

People no longer treat patterns as the shared wisdom of experts, however. They are inclined less to bang their heads against a problem and then consult the Book of Wisdom to see what it says about their particular problem. Instead, they treat patterns as Wal-Mart for decisions. They don’t know what they want, exactly, but hey, this little item here on the shelf looks like a potential candidate.

They start with a pattern and see how to make it fit.

This is bassackwards.

We all build our own patterns around problems we’ve encountered. But just as with design patterns, its important that we force ourselves to think through problems creatively before jumping to more commonly treaded paths.

Loosely following the ZF Quick Start Guide, I copied these rules into my VirtualHost configuration:

<VirtualHost *>
    ...
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} -s [OR]
    RewriteCond %{REQUEST_FILENAME} -l [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^.*$ - [NC,L]
    RewriteRule ^.*$ /index.php [NC,L]
    ...
</VirtualHost>

These rewrite rules didn’t work for me. They basically state, “If the requested file exists and is greater than 0 bytes, or if the requested file is a symbolic link, or if the file is a directory, then don’t rewrite the http request and don’t process any more rewrite conditions or rules for this http request. Otherwise, forward the http request to /index.php”. The logic seemed correct, but requests for existing files were still being forwarded to the ZF front controller (/index.php).

To troubleshoot the problem, I enabled RewriteLog and traced its output. I started at log level 1 and worked my way up to level 4, where I finally found the problem. You can enable the RewriteLog by adding these lines to your VirtualHost configuration:

RewriteLog      /var/log/apache2/dev-rewrite.log
RewriteLogLevel 4

The following is the RewriteLog output for one http request:

[<date>][<host>][<rid>] (2) init rewrite engine with requested uri /tests/info.php
[<date>][<host>][<rid>] (3) applying pattern '^.*$' to uri '/tests/info.php'
[<date>][<host>][<rid>] (4) RewriteCond: input='/tests/info.php' pattern='-s' => not-matched
[<date>][<host>][<rid>] (4) RewriteCond: input='/tests/info.php' pattern='-l' => not-matched
[<date>][<host>][<rid>] (4) RewriteCond: input='/tests/info.php' pattern='-d' => not-matched
[<date>][<host>][<rid>] (3) applying pattern '^.*$' to uri '/tests/info.php'
[<date>][<host>][<rid>] (2) rewrite '/tests/info.php' -> '/index.php'
[<date>][<host>][<rid>] (2) local path result: /index.php
[<date>][<host>][<rid>] (2) prefixed with document_root to /www/home/velissimo/web/index.php
[<date>][<host>][<rid>] (1) go-ahead with /www/home/velissimo/web/index.php [OK]

The problem became apparent in the three lines printed for log level (4): mod_write was checking if the file “/tests/info.php” existed. That path was incomplete, missing the DocumentRoot prefix (”/www/dev/web/”). The path I expected mod_rewrite to check was: /www/dev/web/tests/info.php

And so I learned this lesson about mod_write:

In VirtualHost context, %{REQUEST_FILENAME} does not expand to the full path of the requested resource as the docs indicate. Instead, it expands to the path of the resource relative to the VirtualHost’s DocumentRoot. This might be a bug, since the Apache documentation is pretty clear that %{REQUEST_FILENAME} should expand to “The full local filesystem path to the file or script matching the request.”

Interestingly, %{REQUEST_FILENAME} expands to the full path when used in .htaccess context.

I should point out that the Zend Framework Quick Start Guide’s suggested rewrite rules were correct. The rules failed for me because I used them in VirtualHost context, while the ZF Guide called for them to be used in .htaccess context. When I moved the rules from my virtual host configuration to an .htaccess file, the rewrites worked correctly.

Still, I preferred to define the rules in the virtual host configuration. I was able to achieve this by changing the rewrite rules to:

<VirtualHost *>
    ...
    RewriteEngine   on
    # The leading %{DOCUMENT_ROOT} is necessary when used in VirtualHost context
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -s [OR]
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -l [OR]
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
    RewriteRule ^.*$ - [NC,L]
 
    RewriteRule ^.*$ /index.php [NC,L]
</VirtualHost>

These rules worked for me on:

• Apache 2.2.9 (single architecture 32 bit binary) running on OSX 10.5.6
• Apache 2.0.54 (64 bit binary) running on Red Hat Enterprise Linux ES release 4.

I hope this helps save you some time or shed light on why Zend Framework’s rewrite rules aren’t working for you.

There aren’t any tools for PHP that identify function usage, the way one might do with Java using Eclipse. The recent release of Zend 6 for Eclipse comes closer with its refactor feature, but only refactors within a single file and not across a project.

I solve this need with a handy grep call. The following grep finds all usage and definitions of a PHP function, and omits results from .svn directories. Just replace FUNC_NAME with the name of the function you’re investigating.

Command line usage

grep -rinE "(function[[:space:]]+|[[:space:]]*::[[:space:]]*|\->|[[:space:]]+)FUNC_NAME[[:space:]]*\(" * | grep -v "/.svn/"

Human readable explanation of the grep syntax

grep -rinE "(
    function[[:space:]]+ |              # match function or method definition
    [[:space:]]*::[[:space:]]* |        # match static method call
    \->|                                # match instance method call
    [[:space:]]+ |                      # match procedural function call
    ,+ |
    )FUNC_NAME[[:space:]]*\(" * |       # SEARCH TERM
    grep -v "/.svn/"                    # omit svn directories

Even more convenient

For the ultimate in grepping convenience (thanks Mike Luton for the tip), copy the following into an executable file in your $PATH:

grep -rinE "(function[[:space:]]+|[[:space:]]*::[[:space:]]*|\->|[[:space:]]+|,+)$1[[:space:]]*\(" * | grep -v "/.svn/"

Name the file “grepf” and call it like so:

grepf some_function_name

Route

In my case I’m using the SSH filesystems included in MacFusion to mount a remote directory as a local folder over an SSH connection. The following steps got MacFusion to work on both my intel based MacBook Pro and my older PowerPC based G4 Powerbook.

1. Install MacFuse.
2. Reboot.
3. Install MacFusion 2.x.
   • Older (1.x) versions of MacFusion are available on Google Code. Note that the older 1.x versions of MacFusion are not compatible with the more current 1.7.x versions of the underlying MacFuse platform. So if you install the current MacFuse platform, you’ll need to go here to get a 2.x version of the MacFusion GUI.
4. Start MacFusion and configure it to connect to the desired hosts.

svnnotify looks reasonable (read the man page). It generates HTML email with colored diffs (not as nice as Trac’s diff engine) and is configurable via CLI options to send email to different addresses based on regular expression matches against the directories affected by the commit.

Example: put this in “/repo/hooks/post-commit”

#!/bin/sh
 
REPOS="$1"
REV="$2"
 
/opt/perl/bin/svnnotify \
    -p $REPOS \
    -r $REV \
    -C -d -H HTML::ColorDiff \
    --from admin@example.com \
    --reply-to somebody@example.com \
    -x foo@example.com="^foo/" \
    -x "team1@example.com,team2@example.com"="^big_framework/" \
    -x other@example.com="^one|^two|^three"

I also looked at svnmailer but it uses unified diff format by default which doesn’t look so nice. You can specify your own diff script via the CLI, but I don’t know of any good ones off hand.

Can anyone suggest a good diff script?
Anybody know offhand if Trac uses a standalone diff engine that I could hook up to svnmailer?

find . -name "*.log" -print0 | xargs -0 grep "xyz"

I still wanted to clean things up so I decided to organize the logs into date based directories. I wrote a Perl script that scans files in a directory, parses a date from each filename (YYYY_MM_DD_…), and moves the file to the appropriate directory. For example, the script moves 2008_03_01_foo.txt to 2008/03/01/2008_03_01_foo.txt and creates the directories if necessary.

#!/usr/bin/perl -w
use strict;
use File::Path;
 
my $year;
my $month;
my $day;
my $dir;
 
while (<*>) 
{
    if (($year, $month, $day) = ($_ =~ /(\d+)_(\d+)_(\d+)/))
    {
        $dir = sprintf("%04d/%02d/%02d" ,$year, $month, $day);
        mkpath($dir) if (!-d $dir);
        rename ($_, "$dir/$_") if (!-d $_) || print "Unable to move $_:  $!\n";
    }
}

I have a Craftsman garage door opener with three buttons on the controls. It uses rolling codes but aside from that all I can tell you is it sucks, its loud, and it never seems to do what I want it to, like opening.

Programming the remote
Audi and Volkswagen vehicles have a built-in garage door opener built by HomeLink. Here’s how to set them up with the Craftsman rolling code garage door opener:

1. Turn the car on.
2. Press and hold buttons 1 and 3 on the car’s HomeLink transmitter until the lights start flashing. Don’t hold your breath, it may take a while.
3. Release the buttons.
4. Press and hold the car’s HomeLink button that you want to program.
5. Hold the Craftsman remote control near the HomeLink transmitter and repeatedly press the big button on the Craftsman remote. The HomeLink transmitter is likely in your rear-view mirror, sun-visor, or near the front right headlight.
6. Release the buttons once the HomeLink lights start flashing faster. You may have to slowly move the remote control around the HomeLink transmitter before the lights start flashing faster.
7. Push and release the “Learn” button on the back of the garage door opener (the big ass motor hanging from the garage ceiling). Holding the “Learn” button down for 5 seconds or so usually clears all the codes (i.e., breaks the connection with all your remote control units).
8. Push the car’s HomeLink button that you want to program (yes, again). You may have to hold the button down for a little while, or prese and release the button a few times.
9. Sha-bam-a-wama! It should work now. But if it doesn’t, you might find helpful information on this thread.

Troubleshooting