Robert Basic's blog

Archive for the 'Programming' Category

A weekend hack

by Robert Basic on August 15th, 2012

For a while now I couldn't really make myself sit down in my spare time and do some programming just for the sake of programming. I'd rather read a book, cruise around on my longboard, or whatever. So, this past weekend I decided to try and "hack" together something in a weekend. To see can I still just sit down and write a piece of software, just because I like love doing it, and not because it's my job.

And yes, yes I can. For the better part of the Saturday and Sunday nights, I was just sitting in front of the computer and turning ideas in my head into bits and bytes. Now, this "app" is nothing revolutionary, nothing exciting, but it feels just damn good that I wrote it.


What does this "app" do? It's an Android app to post pictures from my phone to my server. That's it.

What's good about it, for me, is that it has two parts: the Android app itself, written in Java, and the server side code, written in PHP.

The good part about the server side code is that it's still the technologies I use everyday, but with more... liberty. It's basically just an "old-skul" top-down procedural style script.

The good part about the Android app is, well, that it's an Android app. Something I don't get to do everyday and, even tho it's Java, a "break out" technology from my day to day routine. The workflow is rather simple - pick a picture from the gallery of existing pictures on the SD card and send it to the server in a background, async task. Everything was rather simple and straightforward to write, except for the part on making the HTTP client in Java to work with self-signed certificates. That was scary, and probably deserves a blog post on its own. Probably.

I'll be using this app on a regular, daily basis (hopefully). If anyone's interested, have a look at the photos. Note, at the time of writing this post, there's only one photo; a photo of me writing this very post. Heh.

Happy hackin'!
Tags: hacking, php, android, app, server, pictures, photos.
Categories: Development, Programming, Software.

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'),
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_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:

# based on GtkGrab by @EvanDotPro
function rename_file()
    NEWFILE=$(echo $1 | md5sum | cut -c-5)'.png'
xfce4-screenshooter -r --save=$LOCALPATH
LOCALFILE=$(ls -tr $LOCALPATH | tail -n 1)
rename_file $LOCALFILE
while [ "$I" -lt "$LIMIT" -a -f "$LOCALPATH$NEWFILE" ]
    rename_file $NEWFILE
    I=`expr $I + 1`
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.