ZeroMQ can be a great tool, however, there a few things to keep in mind, especially if you are using it in conjunction with Celery (not as a message broker, I assume you’re using something else like RabbitMQ for this).

It’s not very well documented, but during launch, Celery uses multiprocessing to start the Python workers. On Unix-based systems, multiprocessing uses the fork() system call to spawn new processes. Forking copies the parent process into a new process, which causes an issue with open file descriptors (including sockets). This would also be a problem for Django’s database connection, but Celery will reset that by default.

So, if you are using ZeroMQ inside a Celery task (for logging for example), you need to force the worker to manually close and re-open the ZeroMQ context. You can easily do this using the built-in Celery signal worker_process_init. The following helper module takes care of this:

The sed syntax on OSX is somehow a little different than on linux and I keep forgetting it. To replace content within a bunch of files (recursively) on OSX:

Clearing a RabbitMQ (AMQP) queue is not as straightforward as it should be. Python’s amqplib makes this a bit easier:

Don’t (ever) call [self.view something] in a UIView’s -(id)init method. Why? Calling a UIView’s view will automatically load it if it isn’t already loaded. So in this case, ViewDidLoad will finish before the class is fully initialized (which can cause all kinds of weird bugs).

It makes sense and it’s obvious… after the fact. :)

Sometimes you get stuck, very stuck and nobody seems to be able to point you in the right direction. This was one of those moments. The gist of it goes as follows:

We are instantiating singletons using a very efficient approach as suggested in the book: iOS 5 Programming Pushing the Limits:

At the same time, we observe a property of this shared instance using KVO. Now here is the tricky part. iOS internally implements KVO using class swizzling. This basically means that when you first call addObserver:forKeyPath:options:context: on an object, the framework creates a new KVO subclass of the class and converts the observed object to that new subclass (as I found out after a while). Well, this doesn’t work in combination with the suggested +initialize method to create singletons. In fact, initialize is called twice (once for the superclass, and once for the internally generated subclass).

Conclusion: if you are using KVO, create a (non-strict) singleton using the approach below, it will save you some headaches.