Fixing Django syncr u’Medium 640′ issue
I use syncr to sync photo’s from Flickr. I ran into trouble yesterday when suddenly the script stopped working. I got a KeyError, referring to the u’Medium 640′ value. I had a day full of frustration until I found out Flickr has decided to change the format of the data returned from flickr.photos.getSizes. Medium 640 is a new photo size, also shown on flickr itself.
I made a few adjustments to the Flickr api scripts for syncr, and got it working again. You can download the files below.
Be warned, in order to make it work, you need to:
- update your databases according to the new model. In my case I had to remove the existing Flickr tables and run syncdb to install the new ones.
- if you installed the script on your python path you might need to reinstall it (you can simple install it over the existing installation, no questions asked). Otherwise you can probably just replace the libraries in your sites path or something (I never did it like that).
- restart your server or application.
Also you’re free to ask me questions but I cannot guaranty I can help you, and the script hasn’t been tested properly, I can only confirm that it works for me and that I expect it to do so everywhere, but I can not take responsibility if it doesn’t work.
Please let me know if you used it and if that helped you!
There is an issue open about this at the syncr google-project site: http://code.google.com/p/django-syncr/issues/detail?id=84 , it’s open for anyone (although you might have to subscribe or something, no big deal)
The download:
Here are the files: http://typoclear.nldownloads/flickrfix.zip
Now don’t forget again, store results
Note to self, do this!
/* Unoptimized code:
* foo is not touched inside the loop!
*/
for (uint8 i = 0; i < 100000; i++) {
/* Do something */
if (value_to_check == (foo * 4) % 5 + 6) DoSomething();
/* Do something else */
}
/* Better:
* The used value of foo is calculated outside the loop.
*/
const uint32 bar = (foo * 4) % 5 + 6;
for (uint8 i = 0; i < 100000; i++) {
/* Do something */
if (value_to_check == bar) DoSomething();
/* Do something else */
}
The solution in this post worked for my Media Temple grid container for Django. If you’re hosting your Django site elsewhere this solution might not work. If you try it please post a comment to this article and let me know if it worked out.
I host my clients websites on a Media Temple Grid Server in a Django container. Recently I needed to build in upload functionalities. I used the ImageField in my applications model. However, when I tried to upload a file from the admin app I got 502 proxy errors. I couldn’t find a solution to this so I posted a Support Request (to witch Media Temple always responds quickly and adequately). Next morning I had a solution, it’s as follows:
Although a Proxy Error occurs, what is actually happening is that your application is taking to long to get a file lock and the connection from the web server is timing out.
To correct this, edit the file ’data/python/django/django/core/files/locks.py’ and change the two occurrences of ’lockf’ to ’flock’ These should be in line number 57 and 60. Once you make this change restart your application and see if the proxy error goes away.
It’s simple, but I’d have taken me a very long time to figure this out by myself. If you’re experiencing this problem as well this might work. Be sure to backup locks.py though!
Django is without doubt the most complex framework I’ve ever worked with, jet highest level of productivity by far. It’s a strange fact… One thing I have come to discover though is how hard it is to find out how to “do things the right way”. I’ve done Django for a few weeks now and the feeling is getting stronger that Django’s bulking with super powerful functionalities I don’t know about. That’s why I’ve decided to store everything of that caliber I find in this article.
If you have something to add to this list, please mail me or leave a comment. Furthermore, have fun with my little list!
select_template() for custom layouts:
You can use select_template() for super-flexible “templatability.” For example, if you’ve written a news story and want some stories to have custom templates, use something likeselect_template(['story_%s_detail.html' % story.id, 'story_detail.html']). That’ll allow you to use a custom template for an individual story, with a fallback template for stories that don’t have custom templates.
http://docs.djangoproject.com/en/dev/ref/templates/api/?from=olddocs#the-python-api
Getting objects from the other side of a many to many relationship in your template:
If you need have a many to many relationship in your models, accessing both the parent(s) from a child or the child(ren) from a parent can be very confusing. Trey Piepmeier wrote a short but very clear article in his solutions log explaining how to do both.
Use Django’s basic Comments app for comments:
Django includes a simple, yet customizable comments framework. The built-in comments framework can be used to attach comments to any model, so you can use it for comments on blog entries, photos, book chapters, or anything else.
I was a little surprised with my own comment on Ben Ward’s “Understanding the web”. Assuming you red it, you might find this interesting.
Web based applications WILL be part of the “web”, as you describe it and like I agree the web should be. And they will trough social media (something you completely missed in this article).
With the standardization and centralization of information by, in the end, (probably) Facebook and Google, even “locked away” content becomes “open” again, via services(sorry, some terminology can never be avoided).
“THE web” and “web-based applications” will, in my vision, continue to live side to side, but they will connect more and more. Silk threads will be woven from one to another, in your words. And it will be pretty, I promise;-)
Even, the accessibility of content that we in the past tented to hide behind login screens will become more accessible trough OAuth or whatever better alternatives are to show up. And browser specific applications can even keep their content accessible trough these same methods.
Parts of our community are getting frustrated (extremists in both in the Flash and in the html5 camp for example), and we should be very careful to expel certain possibilities of the web as part of it. If we want an open web, we’re going to need an open mind too.
We shouldn’t be too afraid of “wrong” products popping up, as if these could dirty our pretty web. We all know bad products won’t be used, and only the user can tell what a good product is. Ultimately, it will be that very user who will create the web of tomorrow. I say instead of attempting to “contribute to a better web”, try whatever you’d like to try, and LEARN.
The dangers of the real-time web
Yesterday I stumbled upon Pusher, a service that believes “that the real-time web is fantastic and should be easy to implement”. I was lucky to grab a closed beta key and am about to do some experimenting with it. I have to admit I’m very exited about this service, the concept of real-time has tremendous potential. But with that come great risks too, risks I have to write down to warn you, and not in the least place, myself.
Real-Time web?
First of, what is the “real-time web”? It’s nothing new, actually. You might have heard of RAJAX; reverse-AJAX. It’s a technology that aims to refresh data on the client site when the server decides that data should be updated. You can easily find articles about RAJAX dating from 2006, so it’s actually really retro stuff. There are three “main methods” for achieving this:
- interval: basically make ajax calls to the server every so often;
- piggyback: when some info is requested, look for other data that can be updated, and send that along too;
- the hidden iFrame method: create a hidden iFrame that continues loading forever, creating a channel for the server to send data to whenever required. Instead of iFrames flash movies could be used too, but this – of course – requires flash to be installed.
All three of these techniques have been and are being used today, but you probably didn’t notice. Interval is often used to replace adds with other adds after a while, Hotmail uses piggyback (whenever you open a mail it checks for new mails too), and auction sites often update the latest bids live using hidden iFrames. So in many cases reverse ajax is already being applied.
When speaking of a real-time web, you should be thinking about the effect of the hidden iFrame technique though, for it is the only method that creates a connection from the server to the client. With html5 we get the possibility to create websockets, a native functionality to create a two way connection between servers and clients. There is a good, quite understandable article about it on kaazing.org. In English: the server can use talk to the client using websockets, and html5 browsers are able to create these sockets.
I’m not scared jet!
Now enough about how it works, why is this dangerous? We (the web community) are ready for our next step. We’ve been playing with htm5 and css3 a little, we’ve seen AJAX, we’re connecting everything with everything using open social and REST services, the future of flash is uncertain, and most important: our browsers are (getting) ready too. The only natural thing to do now would be to take it live, make dynamic more dynamic. And that’s where the risk is. I think we’re about to reach a point where things are getting too dynamic, too fast, too unstable.
How the internet could become a living hell
You’re on Facebook (or are living in a cave). And if you’re a “young communication professional with a passion for new media” you’re also on Twitter, LinkedIn, Last.FM, Flickr, Vimeo, YouTube, Skype, Wave, Digg, AND reading a lot of RSS feeds. You might have noticed all these services are continuously interconnecting more and more, especially via Facebook (where doing a great job creating “their” web). And not only do they integrate with each other, but also with every “regular” site on the web, using OpenSocial, “share this” and a “my last tweets” column. You’re also likely to have some great Adobe Flex app on your desktop that keeps you updated with whats happening in your digital life.
While writing this article my TweetDeck said “ping, someone said something” about a thousand times, and my Facebook wall grew with seven updates. And I’m a very average user. Luckily, check how much my Facebook wall had grown, I had to refresh the page. And I could (and actually should, but I can’t find the strength) limit my TweetDeck to only check for new tweets every hour. With a real-time web though, that would become a luxury of the past.
Imagine trying to read someones post on yesterday’s party while it was constantly being pushed up and down by live added, edited and deleted updates from others, while enjoying your colleagues having a discussion about their club sandwich on twitter, while getting informed Harry has joined the “trees are not computers” focus group and Joana liked “slapped with fishsticks, song by regina’s always better”, you’ve got 74 unread mails, 23 Wave updates, and Vince is calling for the third time this our.
This should sound ironic but while I’m writing it down I realize it’s not that far from the reality we’re already facing. Not far enough, that’s for sure. Now imagine all this coming at you in real-time, without delay, whenever some developer think would be appropriate, we’d all go crazy in no time.
Still I’m going to create a real-time web!
Because luckily, the developers, that’s us! We can create great collaboration apps and fantastic help desk services. We could update the weather live, and even allow subtle bing alerts live, as long as they don’t cause a headache.
Enjoy, but code responsibly.
Twitter recently deprecated all API authentication methods for the API, leaving OAuth the only authentication method available. Abraham Williams wrote twitteroauth, a really good php library that handles authentication and calls to the Twitter service too. I had a bit of a hard time implementing it though, so for those with similar problems, here’s what I did.
Abraham’s implementation is a bit different from mine, and should be used for different purposes. My implementation only saves user keys to sessions, meaning that users might have to re-authenticate via twitter every time they want to use it. This often isn’t such a big deal, because once users have accepted your application in connections, there will only be a quick back and forth communication between your site and Twitter. Not a big deal.
Abraham’s implementation is intended to save API keys to a database. This can be a good thing, for example when you have a Twitter feed on a site where you need an account anyway. But I think this doesn’t really cope with the OAuth philosophy.
You’re going to need both the files from the twitteroauth core, and the redirect.php file. Save them where you can find them later. You’ll also need a config.php, looking like this:
define('CONSUMER_KEY', 'your_key');
define('CONSUMER_SECRET', 'your_secret');
define('OAUTH_CALLBACK', 'returning_page');
I have multiple pages that need to run the process of validating keys before doing anything else, so I created a separate file, init.php that runs all checks. Let’s be short about it, to work you need to make it look something like this:
session_start();
$connection; // Make sure connection exists.
/**
* If new tokens have been requested you'll get two GET variables,
* that are used to create a key session that allow's acces
*/
if ( isset ( $_GET['oauth_token'] ) && isset ( $_GET['oauth_verifier'] ) )
{
require_once( 'twitteroauth/twitteroauth.php' );
require_once( 'config.php' );
// If there are old sessions with old tokens running,
// these need to be deleted
if ( isset ( $_GET['oauth_token'] ) && $_SESSION['oauth_token'] !== $_GET['oauth_token'] )
{
$_SESSION['oauth_status'] = 'oldtoken';
header( 'Location: ./clearsessions.php' );
}
// Create a connection object. This object can communicate with the server.
$connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $_SESSION['oauth_token'], $_SESSION['oauth_token_secret']);
// By storing the access token in a session the user
// doesn't have to authenticate with every page load.
// You could save tokens in a database, but that would
// require the user authenticating with your site.
$access_token = $connection->getAccessToken($_GET['oauth_verifier']);
$_SESSION['access_token'] = $access_token;
// Unset separate sessions
unset($_SESSION['oauth_token']);
unset($_SESSION['oauth_token_secret']);
// Check if the authentication is correct
if (200 == $connection->http_code)
{
$_SESSION['status'] = 'verified';
}
else
{
header('Location: ./clearsessions.php');
}
}
// If the session already exist, you'll want to create a TwitterOAuth
// object, that will be your "connection" to twitter
elseif( isset( $_SESSION['access_token'] ) )
{
require_once( 'twitteroauth/twitteroauth.php' );
require_once('config.php');
$connection = new TwitterOAuth (CONSUMER_KEY , CONSUMER_SECRET , $_SESSION['access_token']['oauth_token'] , $_SESSION['access_token']['oauth_token_secret'] );
}
else
{
// I include config even if their is no interaction with twitter,
// you might want to do other stuff here
require_once('config.php');
}
You’re going to want to check if there is a connection with twitter. For example, if a user is not authenticated you could show a “login” button. You can use:
if( !isset ( $_SESSION['access_token']['user_id'] ) ) {
echo 'This app doesn't have access to your twitter. Login before continuing.';
}
Now, to use your connection to make calls to the twitter service on behave of the authenticated user, all you have to do is this:
$content = $connection->get('statuses/friends_timeline');
Some things you’ll also need to know:
- By default this returns twitters response in json format, you can change that by changing the $connection->format property.
- Other call methods are $connection->post and $connection->delete.
- See the Twitter API reference for the URI’s and allowed methods.
Have fun!
