Author Archives: Yuji Tomita

IPython does not respect virtualenvwrappers python init. The simplest solution was found in the comments here: http://blog.ufsoft.org/2009/1/29/ipython-and-virtualenv

alias ipython=’python -c “import IPython; IPython.embed()”‘

http://www.designaesthetic.com/2010/12/19/dkim-with-linodes-dns-manager/

deadwalrus says:

The linode guys responded to my ticket. Apparently adding the site.com is a nono. They informed me that their DNS server automatically appends site.com and that having “_domainkey.site.com” messes it up.

So, I changed the entries from “_domainkey.site.com” to “_domainkey” and it worked properly.

This was not a big deal since the linode team responded so quickly – although this is counterintuitive because it relies on a specific unpublished feature of the linode DNS manager. I migrated over from Slicehost and their DNS servers most definitely require that your txt records be entered as “_domainkey.site.com”.

Ahh well. Thanks again.

This is how mine looks for the DKIM TXT entry:

Leave site.com out of the domainkey.

Name: should be selector._domainnkey
Value: should be the unquoted key=value pairs. This is not immediately clear from DKIM “install” instructions on various websites as they tell you it should be a single line record. Linode DNS manager abstracts this a bit, I guess.

This happens if you install satchmo via pip instead of pointing to the satchmo egg on mercurial.

pip install -e hg+http://bitbucket.org/chris1610/satchmo/#egg=satchmo

Somehow I needed to dig through the source to figure this one out.. it’s not obvious.

From a forms constructor, you must access the widget and its value_from_datadict method, which must be passed a decent length of arguments (self.data, self.files, self.prefix(fieldname)).

Turns out there’s an internal function called `bound_form._raw_value(‘fieldname’)` which will get you the data without typing so much.

Why it’s so hidden? I’m not sure.

Note that you would use this when you don’t have access to the actual, post cleaned form which would have done the type conversion and validation for you.

This raw value is going to be a string.

I debugged this one for hours, thinking it had something to do with my django formset code / dynamic handling of new entries.

It turns out the reason was casued by mismatching tag elements.

I two forms, one in a left column, and another larger full page form starting with the right column; thus I had a form element starting inside of a div block which wouldn’t be closed until the end of the page.

This caused the problem where the browser refused to POST the data.

This type of tag mismatch works if it’s rendered by the server, but not if you dynamically add the elements.

I’ve come up with various theories about why pasting into python doesn’t work, but finally, I discovered iPython’s %cpaste command.

%paste pastes content from your clipboard, but doesn’t work in a remote environment.

Enter %cpaste.

In [109]: %cpaste
Pasting code; enter '--' alone on the line to stop.
: print(Paste Stuff Here)

Enter — and the paste ends cleanly… amazing.

Many social media widgets are parsed upon page load, and thus adding new content via AJAX will not trigger the widgets to rebuild themselves.

Each widget has a different solution to force re-rendering.

I needed them for Twitter, Facebook, and GPlus. Add the following to your AJAX content (or fire it off yourself when you’ve done the AJAX call).

Twitter

$.ajax({ url: 'http://platform.twitter.com/widgets.js', dataType: 'script', cache:true});

Facebook

try { 
    FB.XFBML.parse(); 
} catch(ex) {};

Google Plus

try { 
	gapi.plusone.go();
} catch(ex) {};

The docs don’t tell you that when using `paginate_by` (which is .. amazing by the way. SO easy), the pagination object with the current number, next page, etc. is passed to the template as the variable name `page_obj`.

Maybe I missed that. ?

I was debugging why a particular page suddenly sent my postgresql process through the roof / eating a gig of memory before I shut it down.

I started debugging the SQL itself, and saw a LEFT OUTER JOIN. I was wondering where this magic was coming from…

It turns out the culprit was obvious: by default, a django admin ForeignKey field will list ALL objects in the referenced table. If that table is very large, it will pull all fields for every object there and consume your server.

Simply set the foreign key field in the readonly_fields to prevent this behavior.

For future reference:

su postgres
psql
CREATE USER pg_fulfillment;
GRANT CONNECT ON DATABASE my_database TO pg_fulfillment;
ALTER USER pg_fulfillment WITH PASSWORD 'pw';
REVOKE ALL PRIVILEGES FROM pg_fulfillment;
GRANT SELECT, UPDATE, INSERT ON TABLE mytable TO pg_fulfillment;
GRANT USAGE, SELECT, UPDATE ON SEQUENCE mytable_seq_id TO pg_fulfillment;