Everyone seems to have their own favourite URL shortening service, TinyURL, is.gd, tr.im, pendek.in, and so on. Some even do more than just shorten URLs, e.g. tr.im can track stats.
It’s relatively easy to roll own your own URL shortening service once you know the magic behind it. I’m going to explain the basic idea so you can start rolling out your own.
UPDATE: check out django-shorturls, a Django app recently created by Simon Willison and Jacob Kaplan-Moss, it uses a similar base 62 approach.
Read the rest of this entry »
Many people mistakenly think that “web design” means making a website looks nice. Well, that’s only half of the equation. It’s so much more than just layout. One of the major elements in web design is usability, which roughly means making a website feels nice. The other half of the equation that many people tend to forget. A successful web design normally requires balancing of these two major elements.
Read the rest of this entry »
The Apache httpd that comes with Mac OS X Leopard runs in 64-bit mode, so everything else that’s loaded, including mod_wsgi and psycopg2 must be able to run in 64-bit mode as well. Graham Dumpleton explained this behaviour in a post to the django-users mailing list.
Compiling psycopg2 using MacPorts as well as from the tarball would result in something like this when loaded from a web application that runs on Apache:
ImproperlyConfigured: Error loading psycopg2 module: dlopen(/Library/Python/2.5/site-packages/psycopg2/_psycopg.so, 2): no suitable image found. Did find: /Library/Python/2.5/site-packages/psycopg2/_psycopg.so: no matching architecture in universal wrapper
So all I needed to do was force psycopg2 extension to be built for 64-bit as well as 32-bit. After extracting the latest psycopg2 source, do this instead:
LDFLAGS="-arch ppc -arch i386 -arch x86_64" CFLAGS="-arch ppc -arch i386 -arch x86_64" python setup.py build
Then sudo python setup.py install. After that, check the .so file, it should look something like this:
$ file /Library/Python/2.5/site-packages/psycopg2/_psycopg.so
/Library/Python/2.5/site-packages/psycopg2/_psycopg.so: Mach-O universal binary with 3 architectures
/Library/Python/2.5/site-packages/psycopg2/_psycopg.so (for architecture i386): Mach-O bundle i386
/Library/Python/2.5/site-packages/psycopg2/_psycopg.so (for architecture ppc7400): Mach-O bundle ppc
/Library/Python/2.5/site-packages/psycopg2/_psycopg.so (for architecture x86_64): Mach-O 64-bit bundle x86_64
Don’t forget to restart Apache, and that should be it.
Update: It happened to PIL too, it was giving this error: The _imaging C module is not installed, so I had to do the same thing as above: LDFLAGS=... CFLAGS=... python setup.py build followed by sudo python setup.py install.
xkcd always cracks me up.
As usual, link for the uninitiated.
Revision control is a
wonderful concept. Using revision control has helped me personally in
managing content and source code. Traditionally revision control is used to
track changes in source code files, but people has since extended revision
control to manage other things such as system configuration files, web
pages, term papers, and so on. In this article, I will focus on applying the
revision control concept in managing content in web applications, for
example, like how Wikipedia keeps track of
changes in the articles
(example).
Why?
Having a revision control is really useful when we want to keep a history of
contents in our web applications. This history data can be used to revert
changes to a certain revision, find out by whom and when certain changes are
made, and visualise the differences between revisions. Accidental
overwriting of content is no longer a problem with revision control in
place. Aside from history, revision control can also help in a multi-user
environment where many people may potentially work on the same content. In
my opinion, these are the main benefits of having revision control.
Read the rest of this entry »
Follow