Robert Basic's blog

Archive for the 'Programming' category

Introducing pugdebug

by Robert Basic on April 01, 2015.

In my spare time in the past few months I was working on a tool that would help me in my every day job as a PHP programmer. As you may, or may not, know, I’m using vim as my editor/almost IDE, but one thing that is missing from it is the ability to debug PHP files remotely. Yes, there are a bunch of plugins out there that add debugging to vim, but none of them felt usable for me.

And based on my google searches, there are no standalone remote debuggers for PHP, that work on Linux.

In February this year I started to work on a desktop application that would help me address this issue.

pugdebug

pugdebug  is a PyQt desktop application meant to be used as a remote debugger for PHP, that communicates with xdebug.

It is meant to be a debugger and only a debugger. There are a plenty of (good) IDEs that include remote debugging and I’m not going to start writing another one (although I did start one, once).

The application is still pretty simple, ugly as hell, but it works. Sort of. There are still a few kinks left to sort out and I’m doing my best to write them all down.

It’s dependencies are Python 3.4, Qt 5.4, SIP 4.6 and PyQt 5.4. The read me file should have a bit more details on how to start using it. I know it’s a bit messy to set everything up, but I am working on building executables for different Linux distros. That stuff is hard!

It is lincesed under the GNU GPL v3 license, because PyQt.

Using pugdebug

Start the application, click the start button and then it waits for incomming connections. Load a PHP page to start a HTTP debug session, and pugdebug should break on the first line of your code.

Stepping around the code is possible with the step into, step out and step over commands. At each step, pugdebug will get the current variables state from xdebug and display them.

Double clicking on lines in the code viewer will set breakpoints on those lines. Do note though that there needs to be a debugging session active to be able to set a breakpoint. This will change in the (near) future.

And that’s about it. While I know it doesn’t look like much, this was, and still is, a nice learning experience for me and the best part of it is that I was using pugdebug earlier this week to debug a PHP application I’m working on.

Tags: debugging, pugdebug, pyqt, python, qt, xdebug.
Categories: Development, Programming, Software.

Install PyQt5 in Python 3 virtual environment

by Robert Basic on February 04, 2015.

It’s been a while since I last made something with PyQt, so I decided to check out what’s it like nowadays. I’m curious to see what’s new in Qt5 and how does it differ from Qt4. Qt5 also can run under python 3 so I figured to give it a try.

Fedora 21 comes with both python 2.7 and python 3.4, but the default version is 2.7, which means if PyQt5 is installed through the package manager, it will be installed against 2.7. As I’m not currently in the mood of bricking my laptop by changing the default python version, I decided to install PyQt5 in a python virtual environment. Btw, Fedora 22 should have python 3 by default.

In the code samples below, assume the working directory is always ~/pyqt.

Create a virtual environment

First off, let’s create a virtualenv with python 3.4:

virtualenv --python=python3.4 env

Activate the virtualenv and check the python version to verify:

source env/bin/activate
python --version

And that should print something like Python 3.4.1. Leave the virtualenv active, as that’s where PyQt5 is going to be installed.

PyQt5 dependencies

Cool, now with that set up, let’s get PyQt5 dependencies sorted out:

sudo yum install gcc gcc-c++ python3-devel qt5-base qt5-base-devel

As the documentation says, SIP must be installed before PyQt5. Lets grab the sources, configure and make and install them.

wget http://sourceforge.net/projects/pyqt/files/sip/sip-4.16.5/sip-4.16.5.tar.gz
tar xzf sip-4.16.5.tar.gz
cd sip-4.16.5
python configure.py
make
sudo make install
cd ..
rm -r sip-4.16.5*

Not sure why I had to do sudo make install. Verify sip is installed correctly by starting a python shell and typing in the following:

import sip
sip.SIP_VERSION_STR

That should show the sip version 4.16.5.

Installing PyQt5

All the dependencies should be met now, so let’s install PyQt5.

wget http://sourceforge.net/projects/pyqt/files/PyQt5/PyQt-5.4/PyQt-gpl-5.4.tar.gz
tar xzf PyQt-gpl-5.4.tar.gz
cd PyQt-gpl-5.4
python configure.py --qmake /usr/bin/qmake-qt5
make
make install
cd ..
rm -r PyQt-gpl-54*

This will install PyQt5 with the basic modules such as QtCore, QtWidgets and QtSql. Check the output of the python configure.py step to see what modules will be installed. If you need additional modules in your PyQt5 setup, you’ll have to install additional Qt packages on your system. For example, to get the QtWebKit module, install the qt5-qtwebkit package through your package manager first.

Writing a basic PyQt5 app we can verify that it all works. Save the following as pyqt.py:

import sys
from PyQt5.QtWidgets import QApplication, QMainWindow
if __name__ == "__main__":
    app = QApplication(sys.argv)
    window = QMainWindow()
    window.show()
    sys.exit(app.exec_())

Running it with python pyqt.py should start the application that’s just one small window.

Happy hacking!

Tags: pyqt5, python, virtualenv.
Categories: Development, Programming, Software.

Mocking hard dependencies with Mockery

by Robert Basic on December 23, 2014.

One problem with unit testing legacy applications is that the code has new statements all over the place, instantiating new objects in a way that doesn’t really makes it easier to test the code.

Of course, the easy answer to this is “Just refactor your application!”, but that’s almost always easier said than done.

If refactoring is an option, do it. If not, one option is to use Mockery to mock the hard dependencies.

One prerequisite to make this work is that the code we are trying to test uses autoloading.

Let’s take the following code for an example:

<?php
namespace App;
class Service
{
    function callExternalService($param)
    {
        $externalService = new Service\External();
        $externalService->sendSomething($param);
        return $externalService->getSomething();
    }
}

The way we can test this without doing any changes to the code itself is by creating instance mocks by using the overload prefix.

<?php
namespace AppTest;
use Mockery as m;
class ServiceTest extends \PHPUnit_Framework_TestCase {
    public function testCallingExternalService()
    {
        $param = 'Testing';

        $externalMock = m::mock('overload:App\Service\External');
        $externalMock->shouldReceive('sendSomething')
            ->once()
            ->with($param);
        $externalMock->shouldReceive('getSomething')
            ->once()
            ->andReturn('Tested!');

        $service = new \App\Service();

        $result = $service->callExternalService($param);

        $this->assertSame('Tested!', $result);
    }
}

If we run this test now, it should pass. Mockery does it’s job and our App\Service will use the mocked external service instead of the real one.

The problem whit this is when we want to, for example, test the App\Service\External itself, or if we use that class somewhere else in our tests.

When Mockery overloads a class, because of how PHP works with files, that overloaded class file must not be included otherwise Mockery will throw a “class already exists” exception. This is where autoloading kicks in and makes our job a lot easier.

To make this possible, we’ll tell PHPUnit to run the tests that have overloaded classes in separate processes and to not preserve global state. That way we’ll avoid having the overloaded class included more than once. Of course this has it’s downsides as these tests will run slower.

Our test example from above now becomes:

<?php
namespace AppTest;
use Mockery as m;
/**
 * @runTestsInSeparateProcesses
 * @preserveGlobalState disabled
 */
class ServiceTest extends \PHPUnit_Framework_TestCase {
    public function testCallingExternalService()
    {
        $param = 'Testing';

        $externalMock = m::mock('overload:App\Service\External');
        $externalMock->shouldReceive('sendSomething')
            ->once()
            ->with($param);
        $externalMock->shouldReceive('getSomething')
            ->once()
            ->andReturn('Tested!');

        $service = new \App\Service();

        $result = $service->callExternalService($param);

        $this->assertSame('Tested!', $result);
    }
}

And that should be pretty much it. If nothing else, it should make parts of old code easier to test.

For anyone interested, I put the example code up on Github.

Tags: mockery, php, testing, unit tests.
Categories: Development, Programming.

Xdebug and private /tmp on Fedora

by Robert Basic on December 16, 2014.

This one was a bit weird and needed some figuring out. Xdebug profiler output files were not being generated in the /tmp directory.

I wanted to do some profiling with xdebug. I set all the necessary configuration settings in my php.ini, restarted apache, confirmed xdebug is present and configured correctly with php -i | grep xdebug, appended ?XDEBUG_PROFILE=1 aaaand! Nothing. Nothing in /tmp, the default profiler output directory. Double checked paths, permissions, nope, nothing. No profiler files were generated.

find /tmp -name "cachegrind*"

listed the files in

/tmp/systemd-httpd.service-X9iE20R/tmp/

What the?

Apparently systemd services in Fedora can have this setting called PrivateTmp and services with this setting set to true are started with a private /tmp directory. Something something security.

Well then. I created a /var/log/xdebug directory, changed the owner to apache and set the xdebug.profiler_output_dir to that new directory and all is well again.

Hey, I learned something new today.

Tags: fedora, php, systemd, xdebug.
Categories: Development, Programming, Software.

Ack in vim

by Robert Basic on December 09, 2014.

I started using vim 3, 4 years ago. The way I use it is that I started out with no plugins and with a handful of lines in .vimrc. It is far too easy to cram all kind of stuff into it and then get lost in the myriads of key combinations. To prevent that, I decided to slowly add in bits and pieces I find lacking in my day to day usage of vim. Also allows me to first learn the editor and later the plugins.

Today was an exceptional day as I added not one, but two plugins to vim! And that is a big change for me as the total number of plugins I now use is 4.

The first one I added is ack.vim. It’s a nice little plugin to run ack from within vim and show the results in a split window. It’s rather easy to use, one just basically types :Ack search_string and that’s it. The one thing I immediately disliked is that it sort of gets lost in the subdirectories of a project.

A quick google search found a solution for that little problem as well: vim-rooter. It doesn’t do much, just changes the current working directory of vim to the project root when you open a file.

And that’s basically it. Nice and fast searching with ack from vim.

Tags: ack, plugins, rooter, vim.
Categories: Development, Programming, Software.