As a photo management application, Facebook sucks. But it is something that people actually look at (as opposed to Flickr, which is great, but getting people to log-in or follow special guest pass links is a PITA).

I like to keep all my raw photos locally, using IPTC for comments (which Flickr reads -- I put them in using some custom scripts and the Python bindings of libiptcdata) and geo-tagged in the EXIF data (using my google maps point locator). I figure this way if Flickr goes bust/gets bought by Microsoft all I need to do is re-upload somewhere else.

I was waiting for Flickr to integrate with Facebook in some good way, but I then came across the very useful pyfacebook bindings, which, although being a little light on documentation, is a great way to easily throw my photos into Facebook (it's pending the NEW queue in Debian, see #511279).

My fbupload.py script might be a useful starting point if you want to do the same thing. It batches up photos into lots of 60 (the maximum photos in an album) and automatically creates the albums and uploads the photos, reading the IPTC data for comments. The only problem is that you'll have to sign up for a developer key and start a new application to get a secret key to talk to the API (if you're still reading this, I'm sure you can figure it out!).

posted at: Fri, 09 Jan 2009 23:31 | in /code/web | permalink | add comment (6 others)

There's this thing going around on Facebook suggesting you are smart if you can read a paragaph where the middle letters of the words are scrambled.

Everything old is new again, since I remember reading about this in 2003. As far as I remember being able to read the scrambled text was not related to intelligence in any way.

Anyway, as a Friday afternoon distraction I wrote a little javascript to scramble text.

Ahh, the good-olde Fisher-Yates shuffle algorithm, friend of the first year tutorial!

posted at: Fri, 12 Oct 2007 18:19 | in /code/web | permalink | add comment (4 others)

This might be helpful if you're new to Django and figuring out how to develop and deploy it effectively.

I tend to keep my projects together in a subversion repository, which means I like everything in one place. I develop locally, and then deployment consists of svn update on the remote server. I generally lay things out like below.

/var/www/project
|-- db
|-- django
|   `-- project
|       |-- __init__.py
|       |-- application
|       |   |-- __init__.py
|       |   |-- models.py
|       |   |-- views.py
|       |-- manage.py
|       |-- settings.py
|       |-- urls.py
|-- media
|   |-- admin
|   |   `-- media -> /usr/share/python-support/python-django/django/contrib/admin/media/
|   |-- images
|   |   `-- something.png
|   |-- blah.css
`-- www
    |-- base.html
    |-- application
        |-- something.html

• db stores a SQLite DB -- generally enough for me but of course you can use a "real" database. Because my projects are small, a database backup then consists of a svn ci. You need to make sure the web server has permissions to this. As a hack I link /var/www/project/db/dbfile.db into my local development tree, which generally isn't under /var/www/. This makes it easier to deploy.
• django holds generated stuff, views, models, etc. Run django-admin.py in this directory. Apps live underneath it too.
• media stores static media. I use the Debian packages, so link into the default store for the admin media files, and setup ADMIN_MEDIA_PREFIX in settings.py to be /media/admin/.
• www holds the HTML templates.

I then setup Apache with a snippet like

DocumentRoot /var/www/project

<Location "/">
	     SetHandler python-program
             PythonHandler django.core.handlers.modpython
             PythonPath "['/var/www/project/django'] + sys.path"
             SetEnv DJANGO_SETTINGS_MODULE project.settings
             PythonDebug On
</Location>

Alias /media /var/www/project/media
<Location "/media">
	     SetHandler none
</Location>
<Directory "/var/www/project/media">
	      AllowOverride none
              Order allow,deny
              Allow from all
              Options FollowSymLinks Indexes
</Directory>

This lets Apache serve up the static files, which it obviously does well. The only other trick is getting the Django server to serve up the static stuff when I'm developing with it locally. I add the following to the bottom of urls.py

if "GATEWAY_INTERFACE" not in os.environ:
    urlpatterns += patterns('',
            (r'^media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/path/to/local/dev/project/media/'}),
                )

This makes sure it only serves when it is not running under mod_python.

posted at: Sat, 25 Nov 2006 16:47 | in /code/web | permalink | add comment (0 others)

If you're using the Yahoo! UI Library and Internet Explorer (particularly IE7) and it randomly bails out with "operation aborted", chances are you are calling some object's render method before IE has had a chance to build the DOM (of course, every other browser seems to work fine). More annoyingly, this seems to be a race condition, so you might not always catch it.

Google suggests many things, but the only sure-fire solution appears to be waiting until the load event before trying to call render. Unfortunately, none of the sample code does this.

So, for example, to render a menu bar you would firstly create a function within your private namespace to do it, e.g.

// create a new namespace
YAHOO.namespace("mynamespace");

// create a function in our namespace to render the menu bar
YAHOO.mynamespace.onMenuBarAvailable = function() {
  var oMenuBar = new YAHOO.widget.MenuBar("render-to-this-div", { width:"100%"});
  oMenuBar.render();
}

Then register this to be run on load, e.g.

// Initialize and render the menu bar when it is available in the DOM
YAHOO.util.Event.addListener(window, "load",  YAHOO.mynamespace.onMenuBarAvailable);

This means your menu bar, if written with ul,li elements might flash up as a list before it is re-drawn as the menu-bar you expect; but this is better than the browser crashing.

posted at: Sat, 25 Nov 2006 16:20 | in /code/web | permalink | add comment (6 others)