Creating a Celery Periodic Task on Gondor

I’ve recently been using Gondor as a hosting platform for a business I’m starting. I needed to set up a task to update my search indexes every 30 minutes, so I thought of Celery. Asking in #gondor on freenode, I discovered that the Gondor guys had recently gotten whatever backend was needed to make Celery periodic tasks available on Gondor. They haven’t yet gotten around to documenting it fully, but it turned out to be relatively simple.

Setting up Gondor for Celery:

The Gondor docs have a great page on this. Follow the directions and you should be good. I configured my instance using Redis, so I can’t speak to using Kombu.

One note on using the settings from their docs: you’ll probably want to configure your local settings as well. I set up an if statement to detect if I was running locally or on Gondor than specified which settings to load for Redis, etc. Using platform.node is the best way I’ve found to do this (needs some modification if you’re working with more than one dev):

import platform
if platform.node().startswith('your-hostname'):
    #load your settings
else:
    #load Gondor settings

Setting up Celery for Gondor:

For the purposes of this post, I’m going to assume that you already know how to use Celery. If not, it’s not too complicated, check out the docs here. If you have Celery up and executing normal tasks locally, you’re nearly there already. Running a task periodically just requires that you register that task to run periodically. This page here documents the steps. Locally I was able to tasks running both by specifying when they should run in the settings as well as using the database scheduler, but on Gondor I had to use the database scheduler to get it working (could be error my part, I’m not sure). Look here for directions on setting up the DB scheduler. Basically, all I had to do to get this working was add this to my settings.py file:

CELERYBEAT_SCHEDULER = ‘djcelery.schedulers.DatabaseScheduler’

From this point, go into the Django admin (don’t forget to deploy first). You’ll see this section:

Depending on what you want to do here, you may have different steps, but to get a basic task running, add an Interval (pretty self explanatory) then click on “Periodic tasks.” Then click to add a periodic task, and you should see this:

If you’ve set your task up to register properly, you’ll see it listed in the Task (registered) dropdown. If it’s not there, it’s probably something to do with relative paths (read this). Once you’ve selected the task you want, named it, and set an interval, things should just start working. Gondor handles running the Celery workers and Celerybeat on their end.

Good luck and stay safe out there!

Vocal Attractiveness and Sexual Dimorphism: Why Singers are Sexy

Picture this scene: you sit in a dark bar, feet cold from the snow outside, warmed by slow sipping gin and tonic, listening forlornly to a group of women sing dusky arias. Suddenly a blonde woman of moderate physical looks comes to the stage and starts to sing. Her voice intoxicates you and for those few minutes, you fall madly in love. Something about her voice has captivated you. Seems reasonable enough right? I’ve spent a pretty good amount of time watching and listening to a number of singers performing in various groups: a capella, opera, choral, and others. I suspect anyone with similar experiences can also recall a time where they’ve fallen in love listening to someone sing. Voices can be powerfully alluring, and I’d never really stopped to question it or ask why until I recently stumbled across an study with some interesting insight into the matter. The study is enthrallingly titled: Ratings of voice attractiveness predict sexual behavior and body configuration (click title for full text). Before we get too far into it though, let’s do a brief overview of a concept you’ll need:

WHR and SHR: Waist-to-hip ratio and shoulder-to-hip ratio are cross-cultural indicators of sexual attractiveness in humans; with smaller WHR in women being more attractive, and larger SHR in men being the same.

The Study

The study mentioned above is quite simple in practice. Researchers recorded the voices of 76 females and 70 males (excluding ones who may have damaged their voices from external events such as smoking and clear outliers such as people with accents). The participants were recorded counting from 1 to 10. Participants were then asked to listen to recordings from others and rank them from 1 to 5 (1=very unattractive and 5=very attractive). Each voice was rated 12+-2 times and had approximately the same number of male and female reviewers. People tended to rate voices as similar.

The second part of the experiment was gathering additional data from participants. Each was measured at the shoulders, waist, and hips and their BMI* as well as height and weight were recorded. Roughly half the participants also completed an anonymous questionnaire about their sexual history, including such things as number of sexual partners, number of extra-pair copulation partners (sleeping with someone who’s not your partner), and age of first sexual intercourse, among others.

* As a side note, BMI sucks as a measurement. Healthy, well muscled individuals will often show up as overweight or obese, whereas a someone who is skinny fat could likely be marked as normal, despite being quite unhealthy. For example, at 5’11” and 175lbs, I’m borderline overweight, despite having around 10% body fat and the ability to deadlift 2x my bodyweight. Oh, hey look, a quick google search turned up an article from NPR entitled “Top 10 Reasons Why The BMI Is Bogus” which explains this.

Results and Conclusions:

This study produced a number of interesting results:

Voice and physical characteristics:

  • Men with larger shoulders and smaller waists (higher SHR) were more likely have voices rated as attractive by women and men to a lesser degree.
  • Women with smaller waists and larger hips (lower WHR) were more likely to have voices rated attractive by men.
  • BMI seemed to have no relationship between vocal attractiveness.

Physical characteristics and sexual behaviors:

  • Higher SHR is men were correlated with having sex at younger ages, as well as having had more sexual partners, more EPC and more sexual partners who were in other relationships.
  • Lower WHR in women was correlated with younger age of first sexual intercourse as well as a higher number of sexual partners, EPC partners and partners in other relationships.

Voice and sexual behaviors:

  • Men and women with more attractive voices had sex at younger ages, more sexual partners, EPC and sex with people in other relationships.

The data establishes correlations between physical attractiveness, vocal attractiveness, and sexual behaviors, noting that both physical and vocal attractiveness seems to lead to increased sexual activity. Researchers also offer a potential explanation for the link between physical and vocal characteristics in the form of hormones; noting that sex hormones influence both the emergence of physical sex differences as well as vocal structure during adolescence.

Regardless of the device by which this occurs, we can extrapolate some interesting conclusions about vocal attraction and the link between physical and vocal attraction. Other studies have show that physical attractiveness (as measured by SHR and WHR) are good indicators of health and reproductive status. We can therefore assume that there is likely a correlation between these factors and vocal attraction as well. Authors of this study suggest that because of the high degree of accuracy in predicting health from vocal attractiveness, it may well have been an important part of mate selection throughout our evolution.

What about singers?

Then what about my claim that singing can get you laid? Well, singers which people find more vocally attractive are going to be most likely also more physically attractive, and regardless, vocal attraction also predicts increased sexual activity. As this study indicates, those with more attractive voices tended to have more sexual partners. The act of singing in performance also affords singers a unique opportunity to display the attractiveness of their voices, much as a sport competition allows athletes to exhibit beneficial physical traits.

Learning how to sing is a process of training the voice to sound more attractive. While there are certainly examples of bad singers who have been successful (like Bob Dylan or the guy from Audioslave), most singers strive for success (at least in part) by sounding attractive to listeners. (I should note here that I am blending the concepts of vocal attraction with vocal pleasantness, but I feel that the two are very similar if not the same.)

In a sense, training the voice to be more pleasant (attractive) is a bit like training the body to be more physically attractive. Sexual indicators such as SHR and WHR can be affected by diet and exercise to some degree, and there’s no reason why vocal attraction cannot be trained as well. Certainly not everyone would be able to move from a 1 to a 5 on the scale, but 1 to 3 or 4 to 5 is certainly not out of the question. Imagine a soft-spoken man being coached by a friend to speak more loudly in a bar. This will increase the attractiveness of his voice by making it sound fuller and more confident (words we would use to describe an attractive voice). He has not changed his fundamental vocal devices, but has improved his use of them.

Through both technical and physical training and performance opportunities singers are inadvertently (or perhaps intentionally) going to make themselves more attractive to members of the opposite sex. This will in turn likely improve their chances for sexual encounters.

Converting Django Tests to Use Factory Boy

I heard about Factory Boy this last summer at a Django meetup in LA and figured I’d give it a shot. I ended up using it on a small project and intending to write a post back then, but I got distracted and never finished the project. I’ve been working on another Django site the past month or two and decided today would be a good day to convert all of my partner’s code into using Factory Boy.

First off, Factory Boy is a tool for generating data in tests. Pretty much any project you have is going to need some way of doing this. There are basically 3 options that I can think of:

  1. Use fixtures – this works, but quickly becomes a pain in the ass to maintain. If you change a model, you need to modify your fixtures to keep them up to date.
  2. Use calls to your Model.objects.create() and pass in all the arguments you need. This works, but you end up repeating a lot of code.
  3. Create some sort of factory for building objects. I’ve tried all of these and think #3 is probably the best, and Factory Boy is a lot better implemented than the solution we came up with to solve #3 at Mahalo. Fixtures are very hard to maintain, and making create() calls all over your tests leads to a lot of repeated code.

What I’m doing now is converting #2 into #3. It’s a pretty simple process, here’s the basics for the set up:

  • Install factory_boy – check out the github page for details – https://github.com/dnerdy/factory_boy
  • Set up your app – there’s no specific way you have to do this, but I like to make tests.py into a module and put all my factories in a file inside of that. Here’s the steps for that:
    • $ mkdir myapp/tests
    • $ cp myapp/tests.py myapp/tests/tests.py
    • $ echo “from tests import *” > myapp/tests/__init__.py
    • From here you can start making your factories. I like to call my factory file factories.py ( myapp/tests/factories.py ), but you can call it whatever you want. Don’t call it factory.py though, that gave me some import issues because the package itself is called factory.
  • From here you’re good to start converting your code over.
For me, I decided to do it one model at a time. So let’s look at some code (I’m going to keep it pretty simple, but you’ll get the idea) Here’s my existing code. In this example, the view displays the products in the database, so we create two products and then check to see that they are displayed in this view:
import django.test as django_test
import products.models as products_models
class ProductViewTests(django_test.TestCase):
    def test_basic_view(self):
        product1 = products_models.Product.objects.create(name="Test Product",
            features="Awesome Features")
        product2 = products_models.Product.objects.create(name="Another Test Product",
            features="Even More Awesome Features")
        c = django_test.client.Client()

        response = c.get("/products/")
        self.assertContains(response, product1.name)
        self.assertContains(response, product1.features)
        self.assertContains(response, product2.name)
        self.assertContains(response, product2.features)

So, as you can see, we need a factory to create product objects, let’s put that into our factories.py file:

import factory
from products.models import Product
class ProductFactory(factory.Factory): # factory boy knows this is for the Product model
    name = "Test Product"
    features = "Awesome feature set brah!"

That’s technically all I need to start using the factory to make objects in the database (or not in the database if you don’t want to save them, but that’s up to you to figure out — hint: it’s in the docs.) However, what if you want automagically make objects that don’t all have the same name, you can modify your factory a bit. Factory Boy provides some cool ways to automate things. For this we can use the Sequence object:

    name = factory.Sequence(lambda n: 'Test Product {0}'.format(n))

This will make Products with names like ‘Test Product 1″, “Test Product 2”, etc. Pretty cool huh?

Ok, back to our test code. Let’s pull out the two object creation lines and replace them with our factory.

import django.test as django_test
import products.models as products_models
from products.tests.factories import ProductFactory
# One note here: I tried to import this like the others:
# import products.tests.factories as prod_fac - but it
# kept giving me an import error, so I gave up
class ProductViewTests(django_test.TestCase):
    def test_basic_view(self):
        product1 = ProductFactory()
        product2 = ProductFactory()
        c = django_test.client.Client()

        response = c.get("/products/")
        self.assertContains(response, product1.name)
        self.assertContains(response, product1.features)
        self.assertContains(response, product2.name)
        self.assertContains(response, product2.features)

There you have it. There are a lot more features to Factory Boy, such as having a model generate any other model dependencies it has, but this post is pretty long already, so I’ll save that for later. You can always check out the docs on github too, they’re good.

Fixing Postgres on Mac 10.7 Tiger for Django

I’m currently in the process of downsizing my number of computers to a single laptop (or maybe two… I mean who doesn’t need at least 2 laptops these days?), so I got a used macbook pro from a friend and have been trying to make the conversion to developing on it. So far I’ve spent far more time sysadmining on the mac than I have on ubuntu in the last 2 years. Not worth it for the pretty icons, but I really just go the macbook for the touchpad and battery life which are pretty gangbusters.

Anyways, setting up postgresql. Given that I’m not a Mac guy, I’m not 100% sure that everything I recommend here is the best way to do it, but I figured I’m not the only one who will run into these issues, so here’s my steps:

1) I set up my machine using pydanny’s snippet here: https://github.com/pydanny/pydanny-computer-setup/blob/master/mba-osx-lion.rst.

Here’s the postgres part:

$ sudo sysctl -w kern.sysv.shmall=65536
$ sudo sysctl -w kern.sysv.shmmax=16777216

Basically, what this is doing is setting up 2 kernel memory management values. If you are curious and want to see what the values are previous to changing them, you can do this:

$ sudo sysctl kern.sysv.shmall
$ sudo sysctl kern.sysv.shmmax

Then you use brew to install postgres and initialize a database to store all the info that postgres needs to run. The final command then is to actually start postgres running (the -D command specifies where the database you just initialized is located).

$ brew install postgresql
$ initdb /usr/local/var/postgres
$ postgres -D /usr/local/var/postgres

You probably don’t want to have to type that whole business out every time you want to reload/stop/start postgres though, so put this in you ~/bash_profile:

export PGDATA='/usr/local/var/postgres/'

Now you can leave off the -D /path/ part. Just type pg_ctl start to start up postgresql.

Troubleshooting

So that may have worked perfectly for you, but it didn’t for me.

Issue #1: Postgres comes bundled with Lion, or rather some someone decided that they would just put a box filled with shit into the OS and write postgres on it and hope no one noticed. Because of this, when you try to run psql, you’ll get a permission error. Bash is trying to use the wrong version of psql or whatever postgres binary you’re trying to run. To fix this, you need to put the brew installed binaries first on the path. Put this in your ~/.bash_profile:

export PATH=/usr/local/bin:$PATH

Issue #2: The kern.sysv.shmall and shmmax values from above didn’t work for me. It was working for a bit, but then stopped (weird huh? I’m thinking maybe that the shmall/shmmax that I set earlier got unset somehow). I kept getting nasty messages like this:

$ pg_ctl start
server starting
$ FATAL:  could not create shared memory segment:
Cannot allocate memory 
DETAIL:  Failed system call was shmget(key=5432001, size=16498688, 03600).
HINT:  This error usually means that PostgreSQL's request for a shared 
memory segment exceeded available memory or swap space, or exceeded your
kernel's SHMALL parameter.  You can either reduce the request size or 
reconfigure the kernel with larger SHMALL.  To reduce the request 
size (currently 16498688 bytes), reduce PostgreSQL's shared_buffers
parameter (currently 1536) and/or its max_connections parameter 
(currently 104).
The PostgreSQL documentation contains more information about 
shared memory configuration.

After spending a while reading the documentation and lamenting how much easier this would be if Apple spent as much time making their development environment work as they did printing money, I finally just upped the values a lot

$ sudo sysctl -w kern.sysv.shmmax=32768000
$ sudo sysctl -w kern.sysv.shmall=8000

One note on this: the shmall value is a value in pages (which are 1024 bytes * 4). The shmmax value (from what I could tell) has to be 4096*shmall, so I just picked a random value and now it works.

Issue #3: Django was giving me a connection error when trying to run syncdb (oddly enough, dbshell worked. I think this may have something to do with reading vs. writing, so it could be my fault). Here’s the last bit of traceback:

.../python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 140, in _cursor
    self.connection = Database.connect(**conn_params)
psycopg2.OperationalError: could not connect to server: Permission denied
	Is the server running locally and accepting
	connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?

Someone in #django was kind enough to point me in the direction of this fix: change the HOST value in the database dictionary in settings.py to this:

'HOST': '/tmp',

Ok, so I agree. WTF. But everything seems to be working now, so I’m just going to roll with it. Hope this helps someone out there.

 

Life-Mod: Physical State-Anchoring

I was recently watching a video on YouTube about how to spot a liar and toward the end of the movie, the guy mentioned something interesting. He has physical cues for himself which he uses to trigger certain states. Touching his pointer finger to his thumb recalls the state of meditation for him which helps him suppress micro-expressions when he’s negotiating. He also will raise his right big toe when he needs to remind himself to be patient with people that he doesn’t care for.

Hearing this set me to wondering: could I train myself to recall or trigger certain mental states by linking them in my mind with a physical action? I have heard of athletes doing similar things to get themselves into the zone for a play or a game, so I see no reason why it wouldn’t work.

My first cue to try is to remember not to display submissive/defensive body language. My main problem on this is when I’m tired, I will make bad eye contact and avoid confrontational situations or display generally defensive posture.

So far this seems to be working, I’m not sure if it’s actually that the physical cue is actually helping, but it does aid in reminding myself to be aware of my actions. So perhaps that alone is worth the effort.