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'!

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'!

Over the weekend I finally had enough of wordpress and the bloat it became, so I ended up writing my own blog engine thing. Basically I just slapped together all the ZF modules and pieces I wrote over the past few years.

The main goal was that the front end should remain as it was under wordpress. Think I got that part pretty well, even improved it in a few places (for example using sprites for the smaller icons, the header image is finally clickable ...). Gave a short thought about changing the theme, but even tho I'm using it for 3.5 years now, I still like it, so it stays as it is.

The old content is pretty much all here; posts, tags, categories and comments are all imported. I intentionally left out the "pingbacks". Probably will end up writing a separate post just about the importing of the content.

The admin area still needs some work, but it's in usable state. If anyone is interested, the "template" I'm using for the admin area can be found on Github, uses Dojo a lot. I still haven't decided will I end up open sourcing all of the PHP code, don't think there's anything new or "revolutional" in it - just good ol' time proven ZF code.

Currently my main "concern" is the RSS feed, hopefully I didn't break it. If you notice anything broken with the site, please leave a comment or give me a shout on twitter.

Happy hackin'!

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'!

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'!