roam

With regards to args and kwargs? None. Your callable is basically replaced with a Task instance that’s not callable. You need to invoke its enqueue(*args, **kwargs) method and yeah… that’s of course not typed.

Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations.

That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configuration file.

We opt for configuration files. We opt for IDEs that can interpret Spring configuration files which means typos or incorrect dependencies do show up. This allows us to swap out implementations in case shit goes down without having to recompile, connect over a VPN to a remote desktop and hop through a few more hoops to get our class file on the other side. If you're not running your own apps on infrastructure you control (we should be so lucky), you have to take this sort of stuff into account. I'd love to be able to say "This is how stuff's set up. Deal with it."

(And when shit goes down, it is usually not at the place you were expecting it to happen, which means all kinds of configuration options for your bootstrapper would probably still fall short.)

No doubt for styling purposes.

Off-topic, but a heads up to the Mixpanel team: your announcement email sucked. A single big image containing all text? Come on. You guys can do better than that.

Fantastic!

What the hell does it do? I'm not signing up without knowing a single thing about this service.

Seriously? Nine out of ten companies will turn "make it suck less" into "make it even better". Apple dropped the ball, Apple does some very questionable things, but please stop this idiotic bashing, whether it's targeting Apple, Microsoft, Google or even RIM. Just stop it.

I imagine most of those icky suggestions are coming from people who used to run php on hosts with a lot of restrictions. You're right, this should definitely be a part of a best practices guide.

What's confusing you? (I'm trying to help, not being snarky)

If you want to invoke some Django-based logic at regular intervals without having to install Celery (and monitoring and a decent queue) you'll opt for a management command. The link you posted should help you out here. Invoking the script yourself or telling cron to invoke it for you shouldn't be hard if you know about cron.

With regards to Celery: I think the tutorial and docs are pretty clear on how to use it and how to set it up.