I am not usually fond of doing much frontend stuff, but I do like to dable in some javascript from time to time. Nothing fancy, no node.js, coffeescript and the likes for me. I still feel like making applications on the server side, and have the client just show things to the user. If needed some 3rd party javascript library or framework to make my life easier, and that’s about it.

For a while I was trying to figure out how to convert the Gnucash XML file to an SQLite3 database. From version 4.2, Gnucash supports PostrgreSQL, MySQL and SQLite3. Since then, the conversion is apparently simple as choosing File -> Save As … and picking a different data format. Thing is, my Gnucash instance didn’t have that! After some google-fu, turns out I was missing a library called libdbi-dbd-sqlite. After installing the missing library, suddenly the save works as it should. Why Gnucash didn’t pull this dependency (even if it’s optional) when I first installed it, is beyond me. But it’s there now and I can be on my marry way to draw fancy graphs with all this easily accessible, sweet data.

Porting this blog to Zend Framework 2, I decided to write some unit tests as well, while I’m at it. Not that the current code base doesn’t have unit tests, just it doesn’t have much of it… Anyway, I’d like to show how to get unit tests for modules up and running, as well how to throw in Mockery in the mix, as it can help us greatly with mocking out objects. Some of the parts shown here probably could be written in a more cleaner/nicer way, especially the autoloading bit, but so far it works for me.

Zend Framework hit a big milestone as version 2 was released last week. Sadly, I didn’t have time to contribute to it, or even to poke around it much. I decided to slowly, as time permits, port this blog to ZF2; it should be a good enough learning playground.

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.

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.

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:

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

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.