Except I'd not done it myself. This is how I got there.

Sean's approach uses Github webhooks, which are a fantastic concept. Basically, once your commit completes, Github will send a JSON-encoded payload to a specific URI. Sean uses this to trigger an API call to a specific page in his website, which will then trigger a deployment activity.

Awesome, this should be easy; I already have a deploy script written that I trigger manually.

One small problem: my site, while in Git, is not on Github. I maintain it on my own Gitolite repository. Which means I needed to write my own hooks.

I originally went down the route of using a post-receive hook. However, I had problems determining what branch the given commit was on, despite a variety of advice I found on the subject on StackOverflow and git mailing lists. I ended up finding a great example using post-update, which was actually perfect for my needs.

In order to keep the post-update script non-blocking when I commit, I made it do very little: It simply determines what branch the commit was on, and if it was the master branch, it touches a specific file on the filesystem and finishes. The entire hook looks like this:

#!/bin/bash
branch=$(git rev-parse --symbolic --abbrev-ref $1)
echo "Commit was for branch $branch"
if [[ "$branch" == "master" ]];then
    echo "Preparing to deploy"
    echo "1" > /var/local/mwop.net.update
fi

Now I needed something to detect such a push, and act on it.

I considered using cron for this; it'd be relatively easy to have it fire up once a minute, and simply act on it. But I decided instead to write a simple little daemon using perl. Perl daemons are trivially easy to write, and if you use module such as Proc::Daemon and follow a few trivial defensive coding practices, you can keep memory leaks contained (or at least minimal). Besides, it gave me a chance to dust off my perl chops.

I decided I'd have it check for the file in 30 second intervals, simply sleeping if no changes were detected. If the file was found, however, it should attempt to deploy. Additionally, I wanted it to quit if it was unable to remove the file (as this could lead to multiple deploy attempts), and log success and failure status of the deploy. The full script looks like this:

#!/usr/bin/perl
use strict;
use warnings;
use Proc::Daemon;

Proc::Daemon::Init;

my $continue = 1;
$SIG{TERM} = sub { $continue = 0 };

my $updateFile   = "/var/local/mwop.net.update";
my $updateScript = "/home/matthew/bin/deploy-mwop";
my $logFile      = "/var/local/mwop.net-deploy.log";
while ($continue) {
    # 30s intervals between iterations
    sleep 30;

    # Check for update file, and restart loop if not found
    unless (-e $updateFile) {
        next;
    }

    # Remove update file
    if (!unlink($updateFile)) {
        # If unable to unlink, we need to quit
        system('echo "' . time() . ': Failed to REMOVE ' . $updateFile . '" >> ' . $logFile);
        $continue = 0;
        next;
    }

    # Deploy
    system($updateScript);
    if ( $? == -1 ) {
        system('echo "' . time() . ': FAILED to deploy: ' . $! . '" >> ' .  $logFile);
    } else {
        system('echo "' . time() . ': Successfully DEPLOYED" >> ' . $logFile);
    }
}

The system() calls for logging could have been done using Perl, but I didn't want to deal with additional error handling and file pointers; simply proxying to the system seemed reasonable and expedient.

When all was ready, I started the above listener, which automatically daemonizes itself. I then installed the post-update hook into my bare repository, and tested it out. And it runs! When I push to master, my site is automatically deployed, typically within 15-20 seconds from completion.

Caveats

This solution, of course, relies on a daemonized process. If that process were to terminate, I'd have no idea until I discovered my site didn't refresh after the most recent push. Clearly, some sort of monitor checking for the status of the daemon should be in place.

Also, note that I'm having this update on changes to the master branch; you may need to adapt it for your own needs, depending on your branching strategy.

Finally, this approach does not address issues that might require a roll-back. Ideally, the script should probably log what revision was current prior to the deployment, allowing roll-back to the previous state. Alternately, the deployment script should create a new clone of the site and swap symlinks to allow quick roll-back when required.

Automatic deployment with git and gitolite was originally published 24 June 2012 on https://mwop.net by Matthew Weier O'Phinney.

I've seen this principle used everywhere and in just about every programming situation possible, applied to logical operations, naming conventions, formatting, and even project structure. Everyone has an opinion on these topics, and given free rein to implement as they see fit, it's rare that two developers will come up with the same conventions.

TMTOWTDI is an incredibly freeing and egalitarian principle.

Over the years, however, my love for TMTOWTDI has diminished some. Freeing as it is, is also a driving force behind having coding standards and conventions — because when everyone does it their own way, projects become quickly hard to maintain. Each person finds themselves reformatting code to their own standards, simply so they can read it and follow its flow.

Additionally, TMTOWTDI can actually be a foe of simple, elegant solutions.

Why do I claim this?

Recently, discussing module structure in Zend Framework 2, some folks were arguing that our recommended directory structure invokes the YAGNI principle: You Ain't Gonna Need It. Our recommendation is this:

ModuleName/
    autoload_classmap.php
    Module.php
    config/
        module.config.php
        (other config files)
    public/
        css/
        images/
        js/
    src/
        ModuleName/
            (source files)
    test/
    view/

The argument is that since most modules implement a single namespace, and because we recommend following PSR-0 for autoloaders, it makes sense to simply have the source files directly under the module directory.

ModuleName/
    autoload_classmap.php
    Module.php
    (other source files)
    config/
        module.config.php
        (other config files)
    public/
    test/
    view/

The argument myself and others made was that it makes sense to group the files by responsibility. However, the module system ultimately doesn't care how you organize the module — we've embraced TMTOWTDI, and our only requirement is that for your module to be consumed, you must define a ModuleName\Module class, and notify the module manager how to find it. Anything goes.

How does that bolster my argument about the importance of conventions? It doesn't. What does is what following the recommended structure enabled me to do.

One common concern identified with having a re-usable module system is that you should be able to expose public assets easily: things like module-specific CSS or JavaScript, or even images. The first question that arises when you consider this is: where do I put them in my module? That's why the recommendation includes a public directory. In fact, the recommendation goes a step further, and suggests css, images, and js directories as well.

Now, your modules are typically outside the document root. This is a rudimentary and fundamental security measure, and also simplifies deployment to a degree — you don't need to worry about telling the web server about what it shouldn't serve. But if the modules are outside the document root, how can I expose their public assets?

There are a two possibilities that immediately jump to mind:

• Install scripts for modules, which copy the files into the document root.
• Symlink the files into the document root.

Both are valid, and easy to accomplish. Both raise the same question: where, exactly? What if multiple modules have public assets named the same? how do I refer to my assets withing things like view scripts?

This is where having a convention starts to make sense: having a convention should answer these questions unambiguously.

My answer: public access should be at /css/ModuleName/stylesheetname, or /js/ModuleName/scriptname or /images/Modulename/imagename. It's a dirt-simple rule that fulfills the use cases.

However, I'm now stuck with having to develop either install scripts or remembering to create symlinks — ugh. And that's where having conventions led me to a simple, elegant solution.

I added one line to my Apache vhost definition:

AliasMatch /(css|js|images)/([^/]+)/(.*) /path/to/module/$2/public/$1/$3

The translation:

When I come across a path to CSS, JS, or image files that are in a subdirectory, alias it to the corresponding public asset of the matched module directory.

I dropped this into my vhost, restarted Apache, and now not only were the assets I'd created already served, but any new ones I create are immediately available as well. Having a convention actually simplified my choices and my solutions.

Rapid application development at its finest.

My point is this: there will always be more than one way to do things when you're programming, and you may not always agree with the decisions your team has made, or the component library or framework you're using has made. However, if you poke around a little and play within those confines, you may find that those decisions make other decisions easier, or disappear altogether.

Why Conventions Matter was originally published 11 January 2012 on https://mwop.net by Matthew Weier O'Phinney.

So, without further ado, seven things you may not know about me…

• My actual college degree is in comparative religion. I ended up in the Religion department at the University of Puget Sound (yes, the initials are UPS, which can easily cause confusion with brown, parcel-bearing trucks), due to a line of questioning that occurred during an Artificial Intelligence course I was taking. The instructor was asking if there would be any ethical barrier to unplugging an AI — i.e., since it would be capable of thought, would this be equivalent to "killing" it? My initial response was, "No," because humans consist of more than thought… and then I started wondering a bit about that. My emphasis in religion was in Eastern religions. I have a minor in Mathematics (CS at UPS was actually CS/Mathematics).

• I have an FCC Commercial Radio Operator's License. My parents were volunteer DJs at KGLT while I was growing up, and I did my first radio announcing at… get this… the ripe age of 11. I finally got my license before starting college so that I could be a DJ at the university station… and ended up as the General Manager of KUPS my last two years.

• I had long hair — down to my butt at times — for around ten years. Which likely comes as a huge shock to those of you who have met me at conferences. Ironically, I cut it off just prior to moving to Vermont as part of an effort to increase the success of my job hunt.

• Before I started my programming career, I was a graphics technician. The job immediately prior to my first programming position was with a small book publisher that specialized in bird hunting and flyfishing guidebooks, for which I created maps, scanned and processed images for books, and did book and catalog layout.

• My first Object Oriented Programming was in Perl. If you've ever done OOP in Perl, you'll likely agree with the following statement: OOP in any other language is easy by comparison. I mean, come on, a syntax where the very definition of an object requires that you "bless" a "thingy"? Truly; this is from the "bless" documentation:

  bless REF: This function tells the thingy referenced by REF that it is now an object in the CLASSNAME package. If CLASSNAME is omitted, the current package is used. Because a bless is often the last thing in a constructor, it returns the reference for convenience. Always use the two-argument version if a derived class might inherit the function doing the blessing. See perltoot and perlobj for more about the blessing (and blessings) of objects.

  This made OOP in PHP look easy.

• I hold the degree of shodan in Aikido, though I haven't trained in several years, due to time and travel constraints. I love the movement and flow of Aikido, and always found it very meditative. I also liked working with weapons, especially the bokken (wooden sword). This is why when I say, "don't make me get my clue bat out," you should take heed; I know from experience that white oak leaves a mark.

• I could have been Cal. When Zend first interviewed me, it was for the position of Editor-in-Chief of DevZone. After my in-house interview, I had reservations — I didn't feel experienced or connected enough, and was worried I'd botch it. Fortunately for me, and probably the PHP community in general, they decided to hire me as a PHP developer instead.

So, that's seven things (and quite a bit more, really) about me. And now it's time to tag some others:

• Cal Evans is an obvious choice for me. Besides having worked together for some years, he's a great friend.
• Stefan Koopmanschap, who took a train to Amsterdam just to have dinner and a beer with me.
• Sean Coates, whom I met in an airport on the way back from ZendCon two years ago, who lives less than two hours away, and whom I haven't seen since that ZendCon.
• Lorna Jane Mitchell, with whom I'll be doing a tutorial session on Subversion at php|tek, and who will be clearly flustered by being tagged.
• Ivo Jansch, whom I met almost two years ago, and somebody I admire and respect greatly.
• Ligaya Turmelle, one of my co-authors for "The PHP Anthology," the woman who got me to volunteer as a phpwomen Booth Babe, and now MySQL guru.
• Rob Allen, who has made my job easier by publishing tutorials and now a book on Zend Framework, and who in real-life is a mild-mannered Clark Kent I'd gladly raise a pint with any day.

And here are the rules I'm supposed to pass on to the above bloggers:

• Link your original tagger(s), and list these rules on your blog.
• Share seven facts about yourself in the post - some random, some wierd.
• Tag seven people at the end of your post by leaving their names and the links to their blogs.
• Let them know they've been tagged by leaving a comment on their blogs and/or Twitter.

Seven Things - Tagged by Keith Casey was originally published 2 January 2009 on https://mwop.net by Matthew Weier O'Phinney.

One difficulty, however, is keeping productivity high while staying on IRC. To me, the ultimate client would provide me notifications when somebody mentions my name or a watch word — allowing me to read the channel at my leisure, yet still respond to people in a timely fashion.

I've tried a variety of IRC clients over the months, starting with Pidgin (poor interface for IRC), mirc (huge difficulties figuring out the UI), xchat (not bad, but seemed a bit heavy), Chatzilla (I liked the interface, but once you got many tabs going, it was unwieldy switching around between them; I also hated that Firefox dying or restarting caused Chatzilla to do likewise), and now irssi.

So far, irssi is the best I've tried — I can run it in screen, allowing me to keep it open as long as my machine is running. The interface is reasonable, and cleanly keeps channels separate from private messages. Opening, closing, and manipulating windows is easy. And it's highly scriptable… including in a language I actually use! The perl bindings are top notch, though sometimes cryptic. What's important, however, is that there are plenty of examples out there if you want to try doing something. So, I figured I'd write up a quick plugin to trigger notifications.

I've been using a number of different notification servers for linux, and personally like both gnotify and mumbles. Both are very lightweight and offer network protocols for triggering notifications.

I first tried using gnotify. It has a very, very simple TCP protocol, and I've had success creating messages from the shell, PHP, and perl. Unfortunately, for some reason, using it in irssi displayed some odd behavior: I'd lose the cursor and the ability to enter input from the time a notification triggered until it completed (i.e., the notification disappeared). Forking the process did not appear to help.

So, I decided to try out mumbles. Mumbles is written in python, and has themeable notifications — already a plus. It runs via dbus by default, but can also optionally spawn a server that implements the Growl protocol — making it accessible for any process to send notifications. Additionally, it has a command-line utility for triggering notifications — by default over dbus, but optionally by contacting the growl server, if running.

Growl's protocol is a bit involved, and I didn't want to spend too much time on this. So, I did a quick, dirty hack: I used backticks to trigger the CLI utility. And it works fantastically — no delays whatsoever. Here's the code:

# $HOME/.irssi/scripts/mumbles.pl
use strict;
use Irssi;
use Irssi::Irc;
use vars qw($VERSION %IRSSI);

$VERSION = '0.1.0';
%IRSSI = (
    authors     => "Matthew Weier O'Phinney",
    contact     => 'matthew@weierophinney.net',
    name        => 'Mumbles notifications for irssi',
    description => 'This script enables mumbles notifications for irssi',
    license     => 'New BSD',
    changed     => "2008-12-10"
);


sub mumbles_sig_printtext {
  my ($dest, $text, $stripped) = @_;

  if (($dest->{level} & (MSGLEVEL_HILIGHT|MSGLEVEL_MSGS)) && ($dest->{level} & MSGLEVEL_NOHILIGHT) == 0)
  {
    if ($dest->{level} & MSGLEVEL_PUBLIC)
    {
      mumbles($dest->{target} . " : " . $text);
    }
  }
}

sub mumbles {
    my $message = shift;
    my $response;

    $message =~ s/[^!-~\s]//g;

    `/usr/bin/mumbles-send -g 127.0.0.1 -s "IRC" "$message"`;
}

Irssi::command_bind 'mumbles' => sub {
    my ($message) = @_;
    mumbles($message);
};

Irssi::signal_add({
  'print text'    => \&mumbles_sig_printtext
});

This triggers a notification for any "highlight" event — basically, anytime anybody "says" my name in a channel, or mentions a keyword I've marked for highlighting. Additionally, I created a mumbles command so that I can send test messages (usage: /mumbles "this is the message..."). You could certainly bind to other events, such as topic changes, joins, parts, etc — I'm only interested in highlight events.

You may note the regexp in there. One thing I discovered was that most messages contained control and non-ascii characters that often resulted in unreadable notifications, as well as some nasty messages reported by irssi. The regexp removes anything not in the ascii character set or the set of whitespace definitions prior to emitting the notification.

Something else I needed to do was configure compiz to ensure that the notifications actually popped above my windows. I did this by going into the compiz configuration manager, selecting "General Options", selecting the "Focus & Raise Behaviour" tab, and modifying the "Focus Prevention Windows" to read as follows:

(any) & !(class=Mumbles)

To test it, I placed the script in $HOME/.irssi/scripts/mumbles.pl, and then, in irssi, executed /load mumbles.pl.

Once I had it to my liking, I symlinked it into my $HOME/.irssi/scripts/autorun/ directory, allowing it to run as soon as irssi loads. I can now have irssi running in a screen session, or minimize the terminal, and get notifications — keeping me productive and informed at the same time.

UPDATED 2008-12-12: Added information on how to load the script, as well as fixed the location to the autorun directory. Thanks, @sidhighwind!

Mumbles irssi integration was originally published 10 December 2008 on https://mwop.net by Matthew Weier O'Phinney.

The funny thing is that Textmate is a newcomer, and, of course, vim has had such a feature for years. The thing to remember with vim, of course, is its unix roots; typically if you know the unix command for doing something, you can find what you need in vim. In this case, the key is the vimgrep plugin, which ships in the standard vim distribution.

There are a variety of resources on vimgrep. The vim documentation includes a chapter on it, and a quick google search on the subject turns up some nice tutorials immediately. If you've ever used grep, the syntax is very straightforward:

vimgrep /{pattern}/[g][j] {file} ...

The "g" option indicates that all matches for a search will be returned instead of just one per line, and the "j" option tells vim not to jump to the first match automatically. What does the "g" flag really mean, though, and how are searches returned?

Vimgrep returns search results in what's known as a "quickfix" window, and this is where the vimgrep documentation falls apart… it doesn't explain what this is, or link to it (which would be a nice indication that it actually has a separate topic for this).

The Quickfix window is a pane that shows a search result per line. Each line shows the file that matches, the line number, and the contents of that line:

/home/matthew/git/bugapp/application/controllers/helpers/GetForm.php|10| * @var Zend_Loader_PluginLoader

You can't do much from this window; it simply serves as a visual indicator of what file you're currently looking at from the list. However, in the main window, you can start iterating through the results one at a time, using a subset of the Quickfix commands. As a quick summary:

• :cc will move to the next match in the list
• :cn will move to the next match in the list
• :cp will move to the previous match in the list
• :cr will rewind to the first match in the list
• :cla will fast forward to the last match in the list

When done, you can simply close the Quickfix window/pane, and continue working.

I should note that vimgrep is cross-platform. On *nix-based systems, it defaults to using the native grep command, but it also contains an internal (slower) implementation for use on operating systems that do not provide grep by default. You may also map the command to alternate implementations if desired.

I personally use this feature most with the project plugin. Project maps vimgrep to two different commands: <Leader>g and <Leader>G. The first will grep all files in the current project at the current level; the second does the same, but also recurses into subprojects. This is an incredibly easy way to refactor code, particularly for name changes.

Vimgrep and Vim Project was originally published 21 October 2008 on https://mwop.net by Matthew Weier O'Phinney.

I will admit, though, that one area where I have had IDE-envy is the area of code completion. I often find myself doing quick lookups to php.net or perldoc to determine the order of arguments to a function or method call, or checking for the expected return value. Most of the time, this doesn't take much time, however, so I just live with it.

Today, however, cruising through the blogosphere, I came across an article showcasing some new features of Vim 7.0, and discovered Vim 7's code completion.

Basically, while in insert mode, you can type <C-x> <C-o> to have vim attempt to autocomplete the current keyword. If more than one possibility exists, it shows a dropdown, and you can use your arrow keys to highlight the keyword that you wish to use.

But it gets better! Not only does it do this kind of autocompletion, but it also opens a small 'scratch preview' pane showing the function/method signature — i.e., the expected arguments and return value!

I thought I had little need for IDEs before… now I have even less! Bram and the rest of the Vim team, my hat's off to you for more fine work!

Vim 7 code completion was originally published 19 September 2006 on https://mwop.net by Matthew Weier O'Phinney.

Basically, a number of telcos and cable providers are talking about charging internet content providers — the places you browse to on the internet, places like Google, Yahoo!, Amazon, etc. — fees to ensure bandwidth to their sites. Their argument is that these content providers are getting a 'free ride' on their lines, and generating a lot of traffic themselves, and should thus be paying for the cost of bandwidth.

This is patently ridiculous. Content providers already have to pay for their bandwidth — they, too, have ISPs or agreements with telcos in place, either explicitly or via their hosting providers. Sure, some of them, particularly search engines, send out robots in order to index or find content, but, again, they're paying for the bandwidth those robots generate. Additionally, people using the internet are typically paying for bandwidth as well, through their relationship with their ISP. What this amounts to is the telcos getting paid not just by each person to whom they provide internet access, but every end point on the internet, at least those within the US.

What this is really about is telcos wanting more money, and wanting to push their own content. As an example, let's say your ISP is AOL. AOL is part of Time Warner, and thus has ties to those media sources. Now, those media sources may put pressure on AOL to reduce bandwidth to sites operated by ABC, CBS, NBC, FOX, Disney, PBS, etc. This might mean that your kid can no longer visit the Sesame Street website reliably, because AOL has reduced the amount of bandwidth allowed to that service — but any media site in the TWC would get optimal access, so they could get to Cartoon Network. Not to slam Cartoon Network (I love it), but would you rather have your kid visiting cartoonnetwork.com or pbskids.org? Basically, content providers would not need to compete based on the value of their content, but on who they can get to subscribe to their service.

Here's another idea: your ISP is MSN. You want to use Google… but MSN has limited the bandwidth to Google because it's a competitor, and won't accept any amount of money to increase that bandwidth. They do the same with Yahoo! So, now you're limited to MSN search, because that's the only one that responds reliably — regardless of whether or not you like their search results. By doing so, they've just artificially inflated the value of their search engine — without needing to compete based on merit.

Additionally, let's say Barnes and Noble has paid MSN to ensure good bandwidth, but part of that agreement is a non-compete clause. Now you find your connections to Amazon timing out, meaning that you can't even see which book provider has the better price on the book you want; you're stuck looking and buying from B&N.

Now, let's look at something a little more close to home for those of us developing web applications. There have been a number of success stories the last few years: MySpace, Digg, and Flickr all come to mind. Would these endeavors have been as successful had they needed to pay multiple times for bandwidth, once to their ISP and once each to each telco charging for content providers? Indeed, some of these are still free services — how would they ever have been able to pay the extra amounts to the telcos in the first place?

So, basically, the only winners here are the telcos.

Considering how ludicrous this scheme is, one must be thinking, isn't the US Government going to step in and regulate against such behaviour? The answer, sadly, is no. The GOP doesn't like regulation, and so they want market forces to decide. Sadly, what this will likely do is force a number of content providers to offshore their internet operations — which is likely to have some pretty negative effects on the economy.

The decision isn't final — efforts can still be made to prevent it (the above link references a Senate committee meeting; there's been no vote on it). Call your representatives today and give them an earful. Tell them it's not just about regulation of the industry, but about fair competition in the market. Allowing the telcos to extort money from content providers will only reduce the US' economic chances in the world, and stifle innovation and choice.

Telcos are Attacking the Internet was originally published 28 April 2006 on https://mwop.net by Matthew Weier O'Phinney.

Unfortunately, there's not as simple a way to do this in PHP as in perl. Basically, you need to do the following:

• To display errors:

  • In your php.ini file, set display_errors = On, or
  • In your script, add the line ini_set('display_errors', true);

• To show notices, warnings, errors, deprecation notices:

  • In your php.ini file, set error_reporting = E_ALL | E_STRICT, or
  • In your script, add the line error_reporting(E_ALL | E_STRICT);

Alternatively, you can create a file with the lines:

<?php
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', true);

and then set the php.ini setting auto_prepend_file to the path to that file.

NOTE: do not do any of the above on a production system! PHP's error messages often reveal a lot about your applications, including file layout and potential vectors of attack. Turn display_errors off on production machines, set your error_reporting somewhat lower, and log_errors to a file so you can keep track of what's going on on your production system.

The second part of the question was how to run a PHP script on the command line. This is incredibly simple: php myscript.php. No different than any other scripting language.

You can get some good information by using some of the switches, though. -l turns the PHP interpreter into a linter, and can let you know if your code is well-formed (which doesn't necessarily preclude runtime or parse errors). -f will run the script through the parser, which can give you even more information. I typically bind these actions to keys in vim so I can check my work as I go.

If you plan on running your code solely on the commandline, add a shebang to the first line of your script: #!/path/to/php. Then make the script executable, and you're good to go. This is handy for cronjobs, or batch processing scripts.

All of this information is readily available in the PHP manual, and the commandline options are always available by passing the --help switch to the PHP executable. So, start testing your scripts already!

PHP error reporting for Perl users was originally published 27 March 2006 on https://mwop.net by Matthew Weier O'Phinney.

Okay, so that probably comes as no shocker to those of you who know me, but it's the little things that make me realize it myself.

I've been frequenting Perl Monks for a couple of years now, mainly to garner ideas and code to help me with my personal or work projects. I rarely post comments, and I've only once submitted a question to the site. However, I do frequent the site regularly, and the few comments I've put in — generally regarding usage of CGI::Application — have been typically well-moderated.

Well, yesterday I made a comment to a user asking about editors to use with perl. I was incensed by a remark he made about VIM not having the features he needed. Now, as I said in my comment, I've used VIM on a daily basis for over two years, and I'm still discovering new features — and I've used all of the features he was looking for.

This is where I discovered I'm a geek: my comment made it into the Daily Best for today, peaking around number 5. The fact that that made my day indicates to me that I must be a geek.

Oh — and VIM rules!

Sign of a Geek was originally published 17 November 2004 on https://mwop.net by Matthew Weier O'Phinney.

However, I just noticed a post on the php.general newsgroup where somebody asked what the difference was between them. Semantically, there isn't any; they should contain the same information. However, historically and technically speaking, there is. SCRIPT_NAME is defined in the CGI 1.1 specification, and is thus a standard. However, not all web servers actually implement it, and thus it isn't necessarily portable. PHP_SELF, on the other hand, is implemented directly by PHP, and as long as you're programming in PHP, will always be present.

Guess I have some grep and sed in my future as I change a bunch of scripts…

PHP_SELF versus SCRIPT_NAME was originally published 12 October 2004 on https://mwop.net by Matthew Weier O'Phinney.