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

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

I first planned to write some scripts for this in Python or C, but when I finally sat down over the weekend to hack on this, realized there is a PHP D-Bus extension, thanks to Derick Rethans! As I rarely have the opportunity/need to play with more “obscure” PHP extensions, decided to give this one a spin… (Note: apart from that D-Bus is used for processes communicating with each other, I have zero knowledge about it, so I might be wrong with some things down below.)

Installing D-Bus for PHP

As the extension requires the dbus-devel package, first make sure it is installed:

$ yum install dbus-devel

The installation of the extension itself is pretty easy:

$ pecl install dbus-beta

Add the extension=dbus.so line to your php.ini, restart Apache if needed and have a look at the phpinfo();, there should be an entry for D-Bus listed.

Note that there is no documentation for this extension at the moment, but, luckily, the sources include an examples directory full of goodies! After fiddling around with those for an hour or so, got the basics of the extension figured out.

One thing I haven’t figured out completely, is how to run scripts which use the Dbus extension via the browser, as in those cases the scripts are dying with a terrible X11 error message. So, run Dbus scripts from the console and all should be fine.

The a-ha! moment

What I learned by looking at the examples, is that the Dbus class is used for creating a proxy, which can be used to call methods on the service/application we’re interested in. But, what methods are available, what arguments do those methods accept (if any), and what will they return as a result?

This can easily be found out by introspection. Create a proxy to an object which implements the Introspectable interface and call the Introspect method on that proxy:

<?php

$dbus = new Dbus;

$proxy = $dbus->createProxy("im.pidgin.purple.PurpleService",
                            "/im/pidgin/purple/PurpleObject",
                            "org.freedesktop.DBus.Introspectable");

$data = $proxy->Introspect();

file_put_contents('introspect.xml', $data);

As the result of the introspection is returned in an XML and can be quite big, putting it in a file for easier viewing.

By looking at the XML file, it’s pretty easy to figure out what’s going on; method names, method arguments, their names and types, and the returned result:

With all this information at our disposal, it’s easy to write a script which does something useful, like, listing all the connected accounts and the protocols they are using:

<?php

$dbus = new Dbus;

$proxy = $dbus->createProxy("im.pidgin.purple.PurpleService",
                            "/im/pidgin/purple/PurpleObject",
                            "im.pidgin.purple.PurpleInterface");

$accounts = $proxy->PurpleAccountsGetAllActive();

foreach ($accounts->getData() as $account) {
    if ($proxy->PurpleAccountIsConnected($account)) {
        $username = $proxy->PurpleAccountGetUsername($account);
        $protocolId = $proxy->PurpleAccountGetProtocolId($account);
        $protocolName = $proxy->PurpleAccountGetProtocolName($account);
        echo $username . " is connected on the " . $protocolName
                       . " (" . $protocolId . ") protocol.\n";
    }
}

A sample output would be something like: “robertbasic@irc.freenode.net is connected on the IRC (prpl-irc) protocol.”

Next steps

Of course, this is far from a chat bot which can execute commands on a remote server, but at least we have some foundation to build on. In the coming days I’ll try to figure out how to create a loop which can be used to listen to different purple events – when a contact comes online, a chat is sent, or received, etc.

Also, it is quite fun trying to figure out a PHP extension just by looking at examples and the C source itself. One can learn a lot this way.

Happy hackin’!

P.S.: Code samples are up on Github!

Update 2011-12-26: the 2nd post, listening to dbus signals with php, is published!

The rules are easy:

• Write a post called Oktober(blog)Fest.
• List some of the reasons you like blogs.
• Pledge to blog more the rest of the month.
• Share your thoughts on Twitter with the #oktoberblogfest hashtag.
• If we all blog a little more than we normally would this month, maybe we can be reminded of all of the reasons blogs are great.

Well, here I am, pledging that I’ll be blogging a bit more in the coming days/weeks/months. I really do like blogging, don’t know why am I so lazy about it.

Don’t expect anything revolutionary from me tho, heh. An update or two from this weeks Webkonf and maybe some news from the Zend Framework 2 world :)

Happy hackin’!

Guide to Web Scraping with PHP

My overall impression of the book is that it was worth the time and I’m really glad that I bought it. Matthew did a great job explaining all the tools we have at our disposal for writing web scrapers and how to use them. The chapter on HTTP at the beginning and a chapter with some tips and tricks at the end of the book, fit in great with the rest of the chapters, which are full of code examples. For the first reading, I’d recommend reading the book cover to cover, to get an overall view of all the tools presented, but later the chapters can be read independently.

As I said, the first chapter (actually, the second one, the first one is the introductory chapter :p), deals with the HTTP, especially with the parts of it which are needed for understanding, using and creating web scrapers.

The book then continues on different client libraries we can use to send HTTP requests and receive responses. Libraries like cURL or Zend_Http_Client are explained, but it is also explained how one can create his own using streams (the author does note that you’d be better of with an existing one!). For each of the tools it is described, how to handle things like authentication, redirects and timeouts, amongst others…

The second part of the book deals with preparing the documents for, and with the actual parsing of the data from these documents. Again, different tools are presented and explained, which one to use when and why. If none of the parsing tools can help, a most essential overview of the PCRE extension is given, too.

The book is finished with a nice “Tips and Tricks” chapter, which discusses real-time vs batch job scrapers, how to work with forms, the importance of unit testing… IMHO, without this last chapter, the book would not be finished.

I’m thinking hard right now, what bad things could I say about this book, but I can’t think of any. It is a guide, clear and straight-to-the-point, explaining what tools are there, which one to use and how for writing scrapers and that’s exactly what I wanted to know.

Yep, I’d recommend this book to anyone interested in web scraping with PHP :)

This will be a real test for me because for the 2 and a half years of this blog I’ve published merely 60 posts. Why? Mostly because I was (am?) scared to just write more about things I’m interested in. But, as I really do like blogging and letting my thoughts out I’ll just have to do my best to write more :) and yes, it’ll still mostly be PHP related with some linux or javascript stuff here and there :)

To see who pledged to blog more in March, check out the list on PHPDeveloper or follow the movement on Twitter #ideasofmarch.

Happy bloggin’!

It tells what’s the minimum overall PHP version needed, all the PHP extensions used and the PHP versions and extensions file by file.

Installing PHP_CompatInfo is easy: pear install php_compatinfo and that’s about it. Using it isn’t much harder:

<?php

require_once 'PHP/CompatInfo.php';

$source = '/home/robert/www/Zend/';

$driverType = 'xml';
$driverOptions = array();

$info = new PHP_CompatInfo($driverType, $driverOptions);
$info->parseDir($source);

Include the main PHP_CompatInfo file, set the path to the file or directory you want to check and then just run it. By default it’ll just var_dump the results, which is pretty much OK for a few files and directories. For a library like Zend Framework, I found the XML output to be the best. Besides the var_dumping and XML, there are other options for the output like CSV, a simple HTML table and Text, which is used when using the CLI. Oh, right, you can run it either from the console or from your web browser. PHP_CompatInfo’s documentation is very well written and describes all part of it, so I won’t be bugging you with that.

So yea, this little gem goes right into my box of must have tools.

Why?

First, to answer the question everyone is giving me when I mention I’m writing ape:
“Why the hell do you do that (to yourself)?”

Programming is fun. Programming is interesting. Programming makes me learn new things. I like having fun and I do this to learn more about programming and having even more fun. I’m writing web applications each and every day, so writing a desktop app requires a different way of thinking and leaving my “comfort zone” (altho, I’m quite comfortable in front of the keyboard hackin’ away code). ape is written in python and pyqt, but again, it’s not about the language used, for me it is about programming.

The idea

Netbeans is my main IDE for quite some time now and I love it. I know my way around vim, too. But, netbeans has too many features for my taste – I use SVN, git, (on rare occasions I write them) run unit tests from the console. As for vim, maybe I just don’t get it enough, but I feel less productive with it. Debugging PHP apps ends up var_dump-ing things all over the place. So, basically what I want/need from an editor is grouping files into projects, regex search/replace, code coloring & completion and, of course, file editing.

I plan to write a feature a day. On my personal projects I usually want to push out as much code as I can during one day as I’m highly motivated, but this time want to try a different approach. So far I didn’t got far, figured out syntax highlighting, opening files from a file browser widget thingy and things like that, but more on that in other posts.

If anyone wants to take a look, the source code is up on github. It is licensed under GNU GPL v2, as pyqt is licensed under it and I don’t want to waste my time on figuring out could I use MIT or some other license.

Happy hackin’!

It’s idea is to be a community website for PHP programmers from Serbia and other countries from the region. The idea for this website “hit” me somewhere in April or May I think, while I was lurking the interwebs for some, any PHP communities in the region, user groups, anything really, where local PHP programmers could share ideas, news, interests, etc., but found nothing (well, besides 2 bulletin boards and a few of us on Twitter). So, I decided to try and create one.

Of course, this website is only the first step. The purpose of this website is to share news, articles and whatnot with other programmers, something like Mr. Cornutt does on phpdeveloper.org ;) There’s not much up there yet, but that’ll change soon :) Altho the functionality of the website is pretty simple and I could’ve put it out in like 2 hours with wordpress, I wrote it from scratch (using Zend Framework of course!), just, well, because I can :D Once I tidy up the code and maybe refactor here and there, it’ll be up on github (multiple reasons for putting it up there, but that’s for some other post).

I have other ideas for the future, both online and offline related, but first want to put this website on it’s feet.

So, here’s to a better and brighter future for PHP communities around here!

Happy hacking!

I was trying to load a Front Controller plugin which resides in app/modules/my_module/controllers/plugins/ and not in the “usual” lib/My_App/Plugin/. I want this plugin to be called in every request and I want the plugin file to be under it’s “parent” module.

Here’s what I did: added the path to the plugin and it’s namespace to the Zend_Application_Module_Autoloader as a new resource type and then just register the plugin in the front controller in an other _init method.

Code is better, here’s some:

class News_Bootstrap extends Zend_Application_Module_Bootstrap
{
    /**
     * Autoloader for the "news" module
     *
     * @return Zend_Application_Module_Autoloader
     */
    public function _initNewsAutoload()
    {
        $moduleLoader = new Zend_Application_Module_Autoloader(
                                array(
                                    'namespace' => 'News',
                                    'basePath' => APPLICATION_PATH . '/modules/news'
                                )
                            );

        // adding model resources to the autoloader
        $moduleLoader->addResourceTypes(
                array(
                    'plugins' => array(
                        'path' => 'controllers/plugins',
                        'namespace' => 'Controller_Plugin'
                    )
                )
            );

        return $moduleLoader;
    }

    public function _initPlugins()
    {
        $this->bootstrap('frontcontroller');
        $fc = $this->getResource('frontcontroller');

        $fc->registerPlugin(new News_Controller_Plugin_Scheduler());
    }
}

If anyone knows a better way for doing this, please do share it with me.

Now back to work. Cheerio.