Robert Basic's blog

Archive for the 'Programming' Category

Zend Framework full page cache tips

by Robert Basic on February 11th, 2012
When I started rewriting this blog, I knew from start that I want to use Zend Framework's full page caching, as, I think, that's the best cache for this purpose. Not much going on on the front end, much more reads than writes, no ajax or any other "dynamic" content. While implementing the cache, I ran into two issues.

The first problem was that the cache files were created, but they were never valid - on each request a new cache file was created. It was a noob(ish) mistake - I had two calls to Zend_Session::startSession() in my code, which made the session ID always to change which made the cache validity test to fail. Removed the second call and all was well. Or so I thought...

I moved the code to staging to run some final tests before pushing it live, but the cache started failing again. This time the cache files weren't even being created! The same code works on my machine, fails on staging. The only difference was that I had turned off the loading of Google Analytics in the development environment. But... that can't be it, right? Wrong. On every request the values of the GA cookies are different. The full page cache has a set of settings which dictates what variables are taken into account when creating an ID for the cache: make_id_with_xxx_varialbes where "xxx" is one of get, post, files, session, cookie and by default all are set to true. Setting make_id_with_cookie_variables to false made the cache to disregard the always changing GA cookies which made the cache start working again.

So, if Zend Framework's full page cache starts failing for you, check the contents and behaviours of all the variables - get, post, files, session, cookie - and play around with the cache settings until it starts working again.

Happy hackin'!
Tags: zend framework, full page cache, caching.
Categories: Development, Programming.

Xdebug is full of awesome

by Robert Basic on January 30th, 2012

I'm currently trying to fix a Mockery bug and, while deep in the code, I came across a piece of code which gets eval'd. Mainly to understand better what's going on, I wanted to step debug it. I first set a breakpoint before the eval call and then tried to step into the eval'd code, but that didn't work out, Netbeans just moves along to the next line.

What *did* work, is setting a xdebug_break() call inside of the code that will be eval'd - and BAM! it works! Netbeans picks up the signal and everything works just as with regular code - you can view the values of the variables, step in, step out and step over code.

Xdebug is full of awesome.

Happy hackin'!

Tags: debugging, xdebug.
Categories: Development, Programming.

Creating a chat bot with PHP and Dbus

by Robert Basic on January 8th, 2012

Now that we know how to use DBus to communicate with Pidgin from PHP and how to listen to DBus signals, it's time to put it all together by creating a simple chat bot! Nothing fancy, just a simple script that runs somewhere on some server and, by using a Pidgin account, can respond to some basic queries we send it.

What did we get?

As we want our script to receive messages from an other account, first we need to listen to the ReceivedImMsg event on the im.pidgin.purple.PurpleInterface interface. The data we get with that event is the ID of receiver's account, the sender of the message, the actual message and the conversation's ID (and some flags which we're not interested in):

$interface = "im.pidgin.purple.PurpleInterface";
$method = "ReceivedImMsg";
if ($signal->matches($interface, $method)) {
    $data = $signal->getData()->getData();
    $receiver = $data[0];
    $sender = $data[1];
    $message = $data[2];
    $conversation = $data[3];
}

Of course, this is only for this one event, for data associated with other events see Pidgin's manual.

Who's there?

The event we are listening for will fire for any and all accounts, no matter who is the sender or the receiver of the message. We need to make sure that the receiving and the sending accounts are the correct ones, that the receiver is connected and that the receiver and the sender are contacts, "buddies":

if ($receiver == 2034 && $proxy->PurpleAccountIsConnected($receiver)
    && $proxy->PurpleFindBuddy($receiver, $sender) == 3681) {

The numbers 2034 and 3681 are the account IDs for my accounts I used in this example; you'll need to figure out yours.

Sending a response

Now that we know who's talking to whom, we can act upon the received message, do something with it, create a response message and send it back! The data we got with the event, has the ID of the conversation between the two accounts. We create a new instant message for that conversation and send it on it's merry way with our clever response message:

$im = $proxy->PurpleConvIm($conversation);
$proxy->PurpleConvImSend($im, $responseMessage);

As for what action the script can take upon a new message, is really up to the developer: it can do simple stuff like sending back the current uptime of the server or the current IP, running other tools like usher and sending that result back, or whatever is necessary.

Daemonizing

As this little bot is supposed to run on some server, the easiest way to run it as a "daemon" is to put the script in a background job via nohup:

$ nohup php chat.php &

If needed, creating daemons in PHP can be done too.

And that's about all what's needed to create a chat bot. See a complete example here on Github.

As for, is PHP the right tool for creating this kind of thing, I don't know, maybe, maybe not. What I do know, is that I had fun writing all this and I learned a lot along the way :)

Happy hackin'!

Tags: bot, dbus, events, php, pidgin, signals.
Categories: Development, Programming.

Notes on shell scripting

by Robert Basic on December 29th, 2011

Yesterday I did some shell scripting and thought about writing down the few things learned along the way. Amazing how little needs to be done to learn a lot :)

Result of a command to a variable

First thing I learned is how to "save" the result of a shell command to a local variable:

PHP_BINPATH=$(which php)

By enclosing the command in parenthesis and putting a dollar sign in front of it, will put the result of that command in the variable.

An empty variable

Turns out, a variable can be empty, null. Nothing strange with that, until one tries to do something with that variable. For example:

PHP_BINPATH=
if [ $PHP_BINPATH == "foo" ]
  then
    echo "It's foo"
fi

will die with a strange error: "line 2: [: =: unary operator expected". Problem is that when evaluating it will see if [ == "foo" ] and turns out [ is some reserved command or some such. The fix is to wrap $PHP_BINPATH in double quotes:

PHP_BINPATH=
if [ "$PHP_BINPATH" == "foo" ]
  then
    echo "It's foo"
fi

Pass all the arguments!

When calling some other command from within the shell script, and all the arguments which are passed to the shell script need to be passed to that other command, use "$@" for that:

$PHP_BINPATH usher.php "$@"

This will pass all the arguments to the PHP script which is called from within the shell script.

Happy hackin'!

Tags: bash, console, scripting, shell.
Categories: Development, Programming.

Listening to Dbus signals with PHP

by Robert Basic on December 26th, 2011

In my previous post I described (tried, at least) how to communicate with Pidgin from PHP, by using the Dbus PHP extension.

The good part is that not can we only call different methods against Pidgin's libpurple API, we can also listen to different signals on different events, that are sent via Dbus. Some of the events that are signalled are when a chat message is recieved, a friend comes online, a file is sent, or any other from a list of some 110 different events.

The PHP Dbus extension allows us to watch for one exact signal on an interface, or for all signals on an interface. Of course, we can add watches on multiple interfaces at once.

Watching for signals

Once we know the interface and/or the specific signal we're interested in, we can add a watch on it. This is done by calling the addWatch method on the Dbus object, were the first parameter is the interface, and the second, optional parameter is the exact signal we want to listen to.

<?php

$dbus = new Dbus(Dbus::BUS_SESSION);

// watching for a specific signal
$dbus->addWatch("im.pidgin.purple.PurpleInterface", "ReceivedImMsg");
// or watching on an entire interface
// $dbus->addWatch("im.pidgin.purple.PurpleInterface");
// also can listen to different interfaces at the same time
$dbus->addWatch("org.freedesktop.Hal.Device");

Next, we need a way to actually get these signals when the events occur. For this we are using the waitLoop method of the Dbus class. That method accepts a number as a parameter, which is the number of miliseconds it should wait between requests. If an event happened on the interface we're watching, it will return the signal, which is a DbusSignal; otherwise we'll get a null:


do {
    $signal = $dbus->waitLoop(1000);

    if ($signal instanceof DbusSignal) {
        // even if we watch only for one signal on one interface
        // we still can get rubbish, so making sure this is what we need
        if($signal->matches("im.pidgin.purple.PurpleInterface","ReceivedImMsg")){
            // data is in this weird DbusSet object thingy
            $data = $signal->getData()->getData();
            echo "Got stuff!\n";
        }
    }
} while (true);

Once we got the signal, to make sure that the signal is really the one we're interested in, we call the matches method on it. The first parameter is the interface and the second is the signal.

Each event has (can have? not sure yet) additional data associated with it. To get to it, for some odd reason, we need to call getData()->getData() on the signal; note that this is in case of listening on libpurple's interfaces, not sure about others. Experiment. Also, what kind of data is returned, again, depends on the interface and/or the event - some return arrays, some strings.

Have a look at the Github repo for some more examples (the dbus-signals* files).

In the third, and probably last post in this dbus mini-series, I'll try to build a bot with which I can communicate and issue out commands to.

Happy hackin'!

Tags: dbus, events, listen, php, pidgin, signals, xmpp.
Categories: Development, Programming.