I can’t really believe this - but my little company Hex is one year old! I know it sounds cliche, but it really feels like it was last week when I started this… adventure. It’s been one crazy year, that’s for sure.

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.

2011 has been and gone, all in all an excellent year for me; much better than the few clusterfuck years before. Going into 2012 with tons of positive energy and going to make it even better!

Yesterday I did some shell scripting and thought about writing down the few things learned along the way. Amazing how little needs to be done to learn a lot :)

In my previous post I described (tried, at least) how to communicate with Pidgin from PHP, by using the Dbus PHP extension.

My current, most used set up, includes a laptop and a second screen attached to it. The laptop is always to the left of the second monitor and together they give one big screen with a total resolution of 3046x1050. From time to time, X11 gets confused and shows the same image, with the same resolution, on both monitors.