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

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

Sadly, not everything was perfect. In October my grandmother and one of my uncles passed away. Around the same time my Dad’s shop was robbed, twice. That was a tough period for my parents and the entire family, still not over it completely, but not giving up either! We love and support each other and will get out stronger than ever.

Now that the bad part is out, let’s jump to the awesome part ;)

Life changing decisions

In 2011 I actually had three life changing decisions.

First one in March, when I decided to finally quit smoking. And I did it! After 11 years I finally threw that shit away. Gave me a nice self-confidence boost, gained much needed weight – around 10kgs (now just to prevent that turning into fat and into muscles instead) – and I feel much, much better overall.

For the second one I owe a lot to my parents and to Srdjan Vranac, for their continuos support and making it possible to happen. In May I handed over my resignation at my previous job and in June I started my own company, Hex, and joined up with Vranac. Just this one thing changed my life to better in so many ways that I can’t thank Vranac enough for all he did, and is still doing! Thank you :)

The third decision happened in August when I cut my hair. And nope, I didn’t regret it :)

Friends and conferences

This year I spoke at two conferences, DORS/CLUC in May in Zagreb, and Webkonf in October in Budapest. My talks didn’t turn out that good (heck, the second one was pure horror), but I did make new friends which trumps bad talks any day!

In Zagreb I had the honor to meet fellow hacker Nikola Plejić, who kindly offered me a place to stay during the conference and showed me around the city. Now waiting for him to come to Novi Sad so I can return the favor. :)

In Budapest I met fellow hackers Ferenc Kovács and Dubravszky József. Great people with whom I’d like to grab a beer or two this year :)

Open source and hacking

Contributed to web2project and Zend Framework throughout the year, but somewhere in September got really close to a burn out so I decided to back up a little and have a break. I’m trying to ease my way back in to contributing and general hacking now. Need to be careful though, don’t want to get this close to a burn out again, next time might not see the line.

Started to learn C just for fun. Don’t know what to do with it yet, can’t hurt learning/knowing it.

All in all, awesome year which set the bar high for 2012, but with all this positive energy it will be a piece of cake to fly over it!

Happy hackin’ and a happy new year!

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

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

Anyway, when using dojox.data.HtmlStore as a store for a dojox.data.DataGrid (or any other grid, really), pay attention to the definition of the columns structure which is passed to the grid. I was doing a really stupid thing which cost me a bunch of hours until I finally figured out what was going on.

Let’s take for example this is the given HTML table:

<table id="datastore">
<thead>
  <tr>
    <th>ID</th>
    <th>Name</th>
  </tr>
</thead>
<tbody>
  <!-- body comes here -->
</tbody>
</table>

I was defining the structure for the columns as:

var struct = [[
   { field: 'id', name: 'ID', width: 'auto' },
   { field: 'name', name: 'Name', width: 'auto'}
]];

which was wrong. This is the correct one:

var struct = [[
   { field: 'ID', name: 'ID', width: 'auto' },
   { field: 'Name', name: 'Name', width: 'auto'}
]];

Use what’s in the TH tags for the field properties! I was trying to be clever and use the name of the fields in the database. The worst part is that there will be no errors, the grid will render correctly the header row and a correct number of rows for the data, but! it will show “…” in each column, instead of the actual data.

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!

Anyway, the upgrade from Fedora 15 to 16 went smoothly (although a bit slow, thanks to my shitty internet connection), using the PreUpgrade script/process. I was a bit sceptical about doing an upgrade and not a cleanstall, but gave it a shot after all (note: every time I tried a dist-upgrade with Ubuntu it failed miserably). PreUpgrade was downloading stuff for a bunch of hours and (about) an hour of installing them, the upgrade was… Done. Fedora 16 just booted up and I was using my laptop just as before.

I did the post upgrade steps from the above linked article, but the yum distro-sync step failed; it was complaining something about a “Transaction Check Error” for a libdvdcss package. I simply disabled the rpm.livna.org software source, re-run the distro-sync, it did it’s thing and then re-enabled the source.

The second thing that “wasn’t working” is that Apache and MySQL were not starting on bootup, so I ran chkconfig for both of ‘em:

$ chkconfig --levels 235 mysqld on
$ chkconfig --levels 235 httpd on

Lastly, grub was upgraded to grub2. It was working fine, just that it was showing the grub menu on startup, which is a bit silly given that I’m running only one OS on this machine. Anyway, added the following lines to /etc/default/grub:

GRUB_DISABLE_RECOVERY=true
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=0 # I actually edited this line, from 5 to 0

and ran:

$ grub2-mkconfig -o /boot/grub2/grub.cfg

I also thought for a while that there was an issue with my wifi, that it’s dropping connection randomly, but it only happened once, so I don’t know what to do with it.

Happy hackin’!

Today a pretty big news hit the interwebs: as of today, the CLA is not required any more to contribute to Zend Framework 2! This means anyone can issue pull requests and submit patches to the new version. Note that if you want to contribute to Zend Framework 1, you still need a signed CLA. I’ve decided to write a quick post with additional information and links, to make it easier getting started with the contributions!

Back in July I wrote a post on helping out with Zend Framework 2, so consider this post as a second part of that post ;)

The development is on git. The original repo is http://git.zendframework.com/?a=summary&p=zf, while the one on Github is a mirror which gets updated twice a day. Not that it matters much, as everyone forks the Github version and sends pull requests against that.

The issues are kept on a Jira instance: http://framework.zend.com/issues/browse/ZF2. Please make sure you are actually on the Zend Framework 2 project, as we have a separate project for ZF 1. Create an account on Jira and off you go. If I’m not mistaken, it is connected to the ZF wiki, so you can use that too.

All ZF2 related stuff on the wiki is located in it’s own section. It’s full of goodies, so take your time to browse it.

We hold biweekly IRC meetings: every second Wednesday, 17:00 UTC. The next one is going to be on November 23rd. Prior to each meeting we set up an agenda, vote on it, decide who will be moderator and then just discuss whatever is there to discuss. The meetings are held on the #zf2-meeting channel, on Freenode. All agendas and logs from previous meetings can also be found on the wiki.

We have a separate #zftalk.2 IRC channel devoted to discussing all things ZF2!

Subscribe to the mailing lists; you’ll be especially interested in the “Contributors” section; all big and small things are discussed there.

A new “thing” introduced to the ZF ecosystem are the RFCs. We’re using those when a new architecture is discussed or a rewrite/refactor of an existing component is to be done.

New components need to go through a proposal process. The proposal process is rumoured to get an overhaul, but (hopefully!) it won’t be going away.

There is also a blog set up, so be sure to subscribe to the feed.

Great and exciting times are ahead of us and I welcome all new ZF contributors! :)

Happy hackin’!

ab‘s help pages gives a few possible leads. We can POST data with the -p option, which would be great if we would like to benchmark the login process itself. But, we want to test the page after the login. So we’ll need the ab’s -C option, which allows for passing cookies in cookie-name=value pairs.

The login process itself is done with curl as it allows us to POST data to a server and store cookies received from the server in a cookie jar. curl writes the cookies in a Netscape cookie file format, whatever that is. Sample line is:

# Netscape HTTP Cookie File
# http://curl.haxx.se/rfc/cookie_spec.html
# This file was generated by libcurl! Edit at your own risk.

example.com	FALSE	/	FALSE	0	PHPSESSID	[RANDOM_SESSION_ID]

From this output we’re interested in the [RANDOM_SESSION_ID] cookie value, as the cookie name is simply PHPSESSID and we can just hard-code it. To get the value, we use some obscure *nix magic: grep and cut. grep to grep the line with the PHPSESSID cookie and cut to cut out the 7th column from that line. Easy!

Now that we have the value of the cookie, we just pass it along with ab and done! We’re benchmarking pages behind a login.

The entire script is:

#!/bin/bash

COOKIE_JAR="/tmp/ab-login-cookie-jar"

echo "Logging in..."

curl -c $COOKIE_JAR -d username=user -d password=h4x0r http://example.com/login

echo "Getting the session id..."
PHPSESSID=$(cat $COOKIE_JAR | grep PHPSESSID | cut -f 7)

echo "The session id is:"
echo $PHPSESSID
echo "=================="

ab -n 10 -c 10 -C PHPSESSID=$PHPSESSID http://example.com/loggedin

The script is also on Github here.

Tip: use ab’s -v option to test for HTTP codes and/or redirects to see if you are really on the page you want to be.

Happy hackin’!