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.

• web – Web Browse
• remote administration – Use a terminal
• services – Run servers
• video – Transcode, edit, convert, and Backup DVD’s
• music – Listen to music

A few things Linux hasn’t done well and why I’m considering adding a second OS to my desk here (alongside Linux):

• Money Management – GNUCash is the closest thing here, but doesn’t hold a candle to the financial institution integration MS Money and Quicken can offer
• audible.com – my audible.com content forces me to boot into Windows every few months to add new audio books to my iPod mini
• Music – I’ve made limited use and I’d like to make more use of services like Rhapsody.com, Napster.com, or Yahoo Music to have a wider variety of music to listen to.

There are a few ancillary things that don’t necessitate daily Windows usage, but I do need them occasionally:

• Harmony Remote – make my Harmony remote do new things
• Some multimedia stuff, CNN Video – most of this is going to Flash anyway

Wow, that’s a pretty short list. I had in my head that there were more things I wanted from Windows. Maybe I’ll suck it up and work with GNUCash!

On that note, recently solved things that used to suck about Linux on the desktop:

• Flash 9 – Like it or not, Linux is all about choice, now you have the option of running Flash 9 on Linux.
• DVD Backups: This has gotten easier and easier on Windows; I just tried an amazing piece of Linux software called Thoggen which backs up DVD’s to my hard-drive-based media server with a surprisingly few number of clicks.
• Music Management – Rhythmbox and the new player Banshee have made music management and playback much more manageable on Linux. Keep up the great work!
• Network Manager – the network manager makes wireless/wired connection management a cinch. I highly recommend it!

The name Iceweasel sounds like the odd name of an infant open-source project. Many people give up on Linux read names like Iceweasel and GIMP.

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]