Robert Basic's blog

Archive for the 'Programming' Category

Using the new autoloaders from Zend Framework 1.12

by Robert Basic on June 22nd, 2012

The latest, and last, release of the Zend Framework 1.x series is just around the corner as ZF 1.12.0RC1 was announced this week. As I still have projects running ZF1 I thought about giving the most interesting new feature (for me) a spin - the new autoloaders which are backported from ZF2.

Note: the code below was updated to work with ZF 1.12.0RC2. Should still work with RC1, too.

I decided using the classmap autoloader as the main autoloader, and the good ol' standard autoloader as the fallback autoloader. For the classmap autoloader to work we need to create a classmap. ZF1.12 comes with a tool, located in the bin directory, called classmap_generator.php, which will generate the classmap for us:

$ cd /path/to/project/library
$ php /path/to/zf1.12/bin/classmap_generator.php 

This will generate a PHP file called autoload_classmap.php in the library directory and it will have classname - filename mappings of the classes/files from that directory.

Next, need to change the index.php a bit to tell ZF to use the new autoloaders:

// normal setting up of APPLICATION_PATH and other constants here ...
// Ensure library/ is on include_path
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    get_include_path(),
)));
require_once '../library/Zend/Loader/AutoloaderFactory.php';
// As of ZF1.12.0RC2 the Zend prefix is not autoregistered
// with the standard autoloader, so we need to require explicitly
// the ClassMapAutoloader.php
require_once '../library/Zend/Loader/ClassMapAutoloader.php';
Zend_Loader_AutoloaderFactory::factory(
    array(
        'Zend_Loader_ClassMapAutoloader' => array(
            __DIR__ . '/../library/autoload_classmap.php',
            __DIR__ . '/../application/autoload_classmap.php'
        ),
        'Zend_Loader_StandardAutoloader' => array(
            'prefixes' => array(
                'Zend' => __DIR__ . '/../library/Zend'
            ),
            'fallback_autoloader' => true
        )
    )
);
// set up Zend_Application as normal here ...

and that's about it - the autoloader will load classes from the classmaps, but if it fails to do so, it will fall back to the standard autoloader.

Stripping out require_once calls

The Zend Framework manual has a section on how to improve performance of the framework itself, and one of the suggestion is to strip out the require_once calls from the library. I had to alter that find/sed command combination a bit in order to make it work with the classmaps:

$ find . -name '*.php' \
  -not -wholename '*/Application.php' \
  -not -wholename '*/Loader*' \
  -print0 | xargs -0 \
  sed --regexp-extended \
  --in-place 's/(require_once)/\/\/ \1/g'

If I'm not wrong in reading my "debugging" echo statements, the standard autoloader gets called only once - to load the classmap autoloader itself - everything else is loaded via the classmaps. Pretty cool.

Happy hackin'!

Tags: zend framework, autoloader, classmaps, performance.
Categories: Development, Programming.

Automatically upload screenshots in XFCE4

by Robert Basic on February 13th, 2012
XFCE4 has a nice little tool for making screenshots - xfce4-screenshooter. My only gripe with it is that it can't automatically upload the images to a server and give me the URL to the image (to be honest, it can, but it uploads the images to a shady looking website, and I don't like that). And then one day I saw Evan Coury's GtkGrab - a set of scripts which does exactly what I want! But, sadly, that's for Gnome. So, based on Evan's work, I put together this little script:

#!/bin/bash
# based on GtkGrab by @EvanDotPro https://github.com/EvanDotPro/GtkGrab
function rename_file()
{
    NEWFILE=$(echo $1 | md5sum | cut -c-5)'.png'
}
REMOTE=user@domain.tld:/home/user/screens/
DOMAIN=http://i.domain.tld/
LOCALPATH=/home/user/Pictures/screenshots/
xfce4-screenshooter -r --save=$LOCALPATH
LOCALFILE=$(ls -tr $LOCALPATH | tail -n 1)
rename_file $LOCALFILE
I=0
LIMIT=10
while [ "$I" -lt "$LIMIT" -a -f "$LOCALPATH$NEWFILE" ]
do
    rename_file $NEWFILE
    I=`expr $I + 1`
done
mv "$LOCALPATH$LOCALFILE" "$LOCALPATH$NEWFILE"
scp "$LOCALPATH$NEWFILE" "$REMOTE$NEWFILE"
echo "$DOMAIN$NEWFILE" | xclip -selection clipboard
notify-send "Screenshot uploaded, URL in clipboard"
Save this script somewhere on your computer, configure the DOMAIN, LOCALPATH and REMOTE variables, set the script to be executable and then create a shortcut combination for it via Settings -> Keyboard -> Application Shortcuts. Programs you'll need to have installed for this to work are xfce4-screenshooter, xclip and notify-send. If you don't want to be prompted for the password/passphrase for the scp command each time, set up a passwordless login for your user on your remote server.

Happy hackin'!
Tags: bash, script, xfce4, xfce4-screenshooter.
Categories: Development, Programming, Software.

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.