We were reminded of this lesson at iContact. Just because your software ‘should’ never do something, doesn’t mean you shouldn’t make these rules explicit. An emergency bugfix to our queues at iContact had a trojan horse to allow messages from Client A to be matched with subscribers from Client B. Clearly this is bad, and now we’re putting a patch in to detect and throw exceptions if any situation like this occurs. This is, however, a great example of where things that should never happen are still worthy of writing software to prevent. It’s not shameful, it’s insightful to admit that as a programmer we are human and don’t understand as much as we might like.

declare(ticks=1);

class DaemonRunner {
    public static function exec($className) {
        $argv = $_SERVER['argv'];
        $daemon = new $className($argv);
        $daemon->init();
        while (!$daemon->isDone()) {
            $daemon->run();
        }
        $daemon->shutdown();
    }
}

The first statement is a PHPism. This allows PHP to check for signals every 1 tick. A tick is simply a low-level PHP interpreter step. The way I’ve setup my daemon and signal handling by default, the PHP will finish its current iteration and then quit when receiving a signal. This ensures that the database, and whatever background stuff aren’t left in inconsistent states. As with anything, you’re free to modify, extend, or otherwise alter this behavior.

great for background/async processing of:

• photos
• movies
• reports
• imports of data

advantages:

• use the same codebase as your app
• use the same expertise on your team of programmers

challenges:

• signals
• one thread
• memory (this will have to be a whole separate article)
• starting and stopping

A typical Daemon class I use:

abstract class Daemon {
    protected $done = false;

    public function __construct($argv) {
    }
    public function init() {
        pnctl_signal(SIGTERM, array($this, "onSignal"));
        pnctl_signal(SIGINT, array($this, "onSignal"));

    }
    abstract public function run();
    public function shutdown() {}
    public function isDone() {
        return $this->done;
    }
    public onSignal($signal){
        switch ($signal) {
             case SIGTERM:
             case SIGINT:
                $this->done = true;
                 break;
             default:
                 // handle all other signals
        }
    }
}

As you can see, we’ve started to tackle some of the challenges here. The idea is to handle signals, specifically I usually care about SIGTERM (default when using ‘kill’ on *nix) and SIGINT (from pressing Ctrl-C). Both will cause the program to exit gracefully.

I’ll be posting the class I use to run Daemon’s tomorrow.

The whole talk and its supporting files can also be downloaded.

The Zend Framework proved to be:

• too piecemeal
• incomplete – arguably this is represented by the version number; but this applied to both individual components being incomplete and the lack of a complete offering for a whole application
• in flux – changing each time we updated such that it was difficult to get the newer components without breaking lots of our code
• too rigid – we found it far too rigid and requiring much code diving, without much direction, to redirect some of the logic especially in the Controller framework

All in all, Symfony has proved very easy to use, and has many facets and components I haven’t yet even been able to take advantage of.

Hi, David. This is an interesting approach, but I think it’s a solution to a slightly different problem than teaching someone PHP. Instead, it’s a solution to teaching someone the basics of building a web app and you just happen to use PHP to teach those concepts. A perfectly worthwhile and desirable goal, but different.
…

David Sklar

I agree and disagree with some of the points Sklar (sorry, two David’s makes this confusing) goes on to make. If I may paraphrase, Sklar is raising a point which competes with that raised by Ben in our initial discussion. My initial suggestion in the discussion with Ben indicated that books should start by teaching PHP on the command-line and slowly build up to constructing a very lightweight MVC framework and example application. One of Ben’s chief, and valid, concerns equated selling books about PHP with convincing readers or page-flippers that the book would teach them to build web pages in the first few chapters. Or that individuals might be turned off if they weren’t creating XSS attacks willy-nilly by chapter 3. I think the counter to this that Sklar raised is that by hiding the framework you turn off the people who don’t feel they’re really getting their feet wet with PHP. They feel that by using your framework they aren’t learning the ‘real guts’ of the language.

This clearly relates directly to some of the arguments Sklar makes that other languages face this challenge as well, but PHP perhaps more so than others. PHP digs its own hole here because unlike a .NET, Java, or a ColdFusion, PHP has built its name on easy to learn and get going. You can pay $4.99/month and get a server running PHP in 10 minutes. Writing an application in any of these other platforms can take orders of magnitude longer to setup, there’s an expectation of barrier to entry for learning, and often you have to buy pieces of it like an IDE. Sklar indicates that it’s important to strike the balance between “a way to do things” and “the way to do things”.

The dilemma lies in choosing whether I ask the reader to take on faith that the framework underlying the first half of the book isn’t worth delving into right now, but is worth understanding later and either using the quick framework or garner enough knowledge of the principles to build your own. Or, do I go back to my original plan of introducing PHP on the command-line as we built up a small framework and graduate up to a web page far later in the book.

I have full confidence that either approach might work. I know universities teach Physics both with and without calculus to which I’m sure the physics professors initially said “you can’t teach physics without calculus, it’s heresy!” But, this day in age there’s only one physics. I know my economics professor told me she didn’t like math, but she managed to teach a great class about economics concepts by moving lines back and forth on graphs.

[tags]learning php, programming, computer science, php, php books[/tags]

We sat around the fire on Wednesday night chatting about PHP when Ben Ramsey and I entered an interesting discussion about PHP’s future and how to introduce newbies to PHP.

I’ll define the sterotype which serves as the premise for this discussion. Most books that introduce PHP, even those which rely on previous programming knowledge begin with an example like this:

print "hello world";

This example will be soon followed within the next 1-3 chapters (sometimes after, sometimes before introducing loops, conditions, and other basic language constructs of PHP) by an example like this:

print $_GET['foo'];

In any/all books it’s far later in the book where Object-Oriented programming is covered. In the coverage of creating forms, handling GET/POST/Cookies/Session there’s relatively little talk of security, escaping, or encodings.

The long and short is that people learn PHP in a way that first teaches them to design web applications in a poorly maintainable, insecure, and generally poor method. With the advent frameworks like the Zend Framework and other MVC-based libraries there’s no need to teach bad habits that result in a bad name for PHP.

[tags]php, books, rant[/tags]