A quick post this one. I’ve been scouring the internet trying to find the right settings in order to connect up my pfSense to use BT Infinity’s native IPv6 implementation. Finally found the magic combination, which I’m sharing here for future reference, and hopefully help anyone else that might find this post.

There may end up being an instance or 2 where you need access to the initial request object inside a celery task, for want of forming an absolute URL for an email template that you’re generating asynchronously, amongst many other reasons. However you’ll find that the WSGIRequest object can’t be pickled because of bound methods and lambda’s that exist on the object itself. So when you try to send the task, it’ll fall over raising an Exception stating that the WSGIRequest object can’t be pickled.

No worries! Here we monkey patch WSGIRequest’s __reduce__ method to allow it to be pickled safely. You’ll need to drop this into a file that gets imported relatively early on in the project. What I usually do is have a monkey.py file sitting at the root of my project, and in the settings file simply “import monkey”.

Basically all we’re doing here is creating a new dictionary that only includes the most amount of information that the WSGIRequest object needs to reconstruct itself with. The bound methods that prevent it from being pickled in the first place can be recreated when the pickled object is expanded (and for the most part you’ll probably find you don’t use them anyway). All we really care about is the META, GET, POST, user and the path info, all of which we’re including here. This makes the WSGIRequest object pickle-able, and allows access to a proper request object within a celery task.

I’ve been using this code in production for little over a year now with zero side effects, so I can vouch for its safety.

I’ve never done a hardware review before (with the exception of the odd Amazon review), so bear with me.

For those who’ve been following my rarely updated blog, I’ve been plagued with laptop issues for a while (here, here, here and here – oddly enough all LCD related) so I figured it was about time I found some sort of reliable work horse that I can just *get stuff done* rather than having to faff around with hardware every handful of months (the last post about LVDS cables covers a significant period of time, and recently started playing up again). So it was about time for a change.

You all know that feeling (well, I hope you do!) that when a spike in traffic occurs on your WordPress site, that the miniature server you have it running on very quickly runs out of resources. Apache’s good like that. Taking up all the resources with its large number of processes consuming oodles of memory each. How on earth can you possibly fix it, especially when you’re running on a tight budget and upgrading the server for that once-in-a-blue-moon you get a spike in traffic? Well, Amazon Cloudfront to the rescue!