Tweet Button URL Double Encoding Fix

If you’re adding a Tweet button to a dynamic web page using the goodies page at

https://twitter.com/about/resources/buttons#tweet

then don’t rely on the “Use the page URL” option to supply the tweet url. widget.js will incorrectly encode your url if it has a query string with any % escape characters, and the link in your tweet will actually be broken.  Most people don’t encounter this problem (since generally you would put the Tweet button on a static page with no query string and hence no % characters), but if you do need to put a Tweet button on a dynamic page with an encoded query string in the url, you’ll need to physically specify the data-url param to the link tag with the current page URL.  Don’t leave it to Twitter to determine the current page url – they’ll incorrectly re-encode the url string.

There are a number of reports of this bug on the Twitter forums, but they don’t seem to believe the bug exists and apparently have not fixed it in years.  Just use the data-url param when in doubt and save yourself some hassle.

Advertisements

Django view shortcuts: render_to_response vs. render

If you’re using Django 1.3+, and find your code littered with

from django.shortcuts import render_to_response

def my_view(request):
...
  return render_to_response('my_template.html', my_data,
    context_instance=RequestContext(request))

you can replace that with a call to the render() shortcut, introduced in Django 1.3:


from django.shortcuts import render

def my_view(request):
...
  return render(request, 'my_template.html', my_data)

You should generally prefer render() over render_to_response() – with render_to_response(), if you leave off the context_instance param, Django won’t invoke any of the default template context processors.

See the docs for more details.

Slow Twitter API calls on Ubuntu 12.04 + Parallels VM

While working on some Python scripts on Ubuntu running on a Parallels VM, I noticed that calls to the Twitter REST api were incredibly slow.  I also saw the same problem when just using curl instead of Python. Oddly, it didn’t occur if I just accessed the url from a browser (Chrome). Even more oddly, it only occurs when accessing the Twitter REST api, not arbitrary websites.

The issue can be avoided by switching the VM from Shared networking to Bridged networking.  The problem and workaround is consistently reproducible for me.

Dev setup:

  • MacBook Pro
  • Parallels Desktop 7.0
  • Ubuntu 12.04
  • Python 2.7.3

Script:

test_twitter_api.py:
import httplib

conn = httplib.HTTPConnection("api.twitter.com")
conn.request("GET", "/1/friends/ids.json?screen_name=twitter")
print("status: %d" % conn.getresponse().status)

Shared Networking in Parallels VM:

$ time python test_twitter_api.py
status: 200

real 0m10.135s
user 0m0.028s
sys 0m0.004s

Bridged Networking in Parallels VM

$ time python test_twitter_api.py
status: 200

real 0m0.167s
user 0m0.028s
sys 0m0.012s

The difference is dramatic – the call to conn.request() drops from 10 seconds to a fraction of a second. The above results also hold when just using curl to access the api:

curl --get 'http://api.twitter.com/1/friends/ids.json' \
     --data 'cursor=-1&screen_name=twitter' --verbose

Strangely, the issue only occurs when accessing the Twitter REST api – it doesn’t occur if you’re fetching other urls, or if you access the Twitter REST url from a browser.

So if you’re doing software development on a Parallels VM, make sure to enable Bridged Networking! (Click on the little web icon in the bottom right of your VM window, or go to Virtual Machine → Configure → Hardware → Network)