sean hess

Having your app keep a detailed log can be indispensable for figuring out tricky user-reported bugs. This is easy on the server-side, where you can use any logging framework or just write to a file. Flash includes the trace function, which is useful while developing, but nearly impossible to get from an end-user. Flex, however, has a good logging api that lets you put log statements anywhere you want. I’ve always wanted the interface to be as easy as trace, so I write a couple of scripts to make it easier.

There are two files in there now. The first is log.as. I didn’t realize before that it was possible to define your own package-level functions. Some might disagree with me, but I think this syntax is a lot nicer than the default. It looks just like trace. All it does is create an easy way to access the flex logging api.

import net.seanhess.flog.log;

function stuff():void
{
    log("Executing stuff");
    // do stuff 
    log("Finished!");
}

You can replace all your trace statements with these. It’s easy enough to add a trace target to the logging api, so all log messages are traced. See the Flex Logging API for more details, but here’s how you would do it.

import mx.logging.Log;
import mx.logging.targets.TraceTarget;

// Only once in your app
function addLoggingTargets():void
{
    Log.addTarget(new TraceTarget());
}

The second little tool is a new logging target. I wanted a way to log to a local file in flex, so the support guys could get an end-user to email it. The only way to do this without hacks is to write to a shared object. It turns out if you write an array of strings to a shared object, it’s easily human-readable. You attach SharedObjectTarget like any other target and away you go.

import mx.logging.Log;
import net.seanhess.flog.SharedObjectTarget;

// Only once in your app
function addLoggingTargets():void
{
    Log.addTarget(new TraceTarget());
    Log.addTarget(new SharedObjectTarget("MyCustomAppLogging"));        
}

The file is located in the application data folder, which is in~/Library/Preferences/Macromedia/Flash Player/#SharedObjects on the mac. (Google it for windows). The target does some fancy stuff like automatically saving if it hasn’t received a log message for one second. It also automatically rotates messages once the size reaches about 50k (The default allowed size for shared objects is 100k).

There’s more that can be done here. I might add a debug and an error function. You could easily write an app to send the contents to a server too.

For alternatives and more information look at the approaches of Tom Barker, Virgil Cristea, and John Wilker.

This class and script makes it easy to turn a one-shot php script into a daemon that runs in the background on a timer. This is good for things you want to happen infrequently. For example, your site may need to use curl to fetch several different rss feeds, combining them into one feed. You don’t want to fetch all the feeds every time someone asks for the combined one. It is better to generate the combined feed every 5 minutes or so.

daemon generate_feed.php start
daemon generate_feed.php stop     
daemon generate_feed.php restart

generate_feed.php might look like this

require_once("BlogDatabase.php");
echo "Generating Feed"; // this will go to the log  

$data = new BlogDatabase();
$posts = $data->getAllNewPosts();

foreach($posts as $post)
{
    // generate an rss feed
}                          

file_put_contents("feed.xml", $contents);

Alternatives

• crontab - This is the easiest way to get a script to run on a timer, but there are a few disadvantages. Specifically, you don’t have exact control over the timer, nor can you prevent the script from running if the system isn’t ready. Refer to this article for more information.

• System_Daemon - This was built using System_Daemon. I created this because my daemons were behaving strangely. Our database calls weren’t working properly, and things were just generally messed up.

What it does

This uses the pear System_Daemon to create a daemon that runs your script every 5 seconds (by default). It uses shell_exec to run it, giving you the following advantages.

• Your script runs in a “sandboxed” environment. You don’t have to worry about stale variables or strange processes making your code behave strangely.

• You can test your script by running it on the command-line, since this is exactly what the daemon does.

• You can easily start and stop the daemon using the included tool.

• It puts output from the script into the daemon’s log (/var/log/generate_feed.log on my system)

Sorry it isn’t more flexible right now, but the timer can be easily changed in Daemon.php

Installation

You need to install the pear System_Daemon module. Refer to this article for instructions.

Put your daemons in the same folder as these scripts, or else make sure Daemon.php is in your include path when you run daemon from the command line.