Django: Auto-Creating/Importing Comments using the built-in comments system

While working on a ticket system for a client, I realized it probably would make most sense (for various reasons) to leave certain auto-generated information directly in the comment thread itself.  Code reuse and a single loci of focus for real-time feedback sounded like a winning proposition to me.

Unfortunately, running a Google search for anything in regards to directly using the comments model turned up nothing at all.  I suspected it was because no one dared abuse Django in a likewise manner; or because it was trivial.  Having seen the answer, I’m guessing it’s a bit of both.

The main clue that makes it easy is in the django / contribs / comments / forms file.


def get_comment_create_data(self):
"""
Returns the dict of data to be used to create a comment. Subclasses in
custom comment apps that override get_comment_model can override this
method to add extra fields onto a custom comment model.
"""
return dict(
content_type = ContentType.objects.get_for_model(self.target_object),
object_pk = force_unicode(self.target_object._get_pk_val()),
user_name = self.cleaned_data["name"],
user_email = self.cleaned_data["email"],
user_url = self.cleaned_data["url"],
comment = self.cleaned_data["comment"],
submit_date = datetime.datetime.now(),
site_id = settings.SITE_ID,
is_public = True,
is_removed = False,
)

The first two values are for the item you want to have the comment applied against.  In my case:

# obj = the object we want to save.
from django.contrib import comments
from django.contrib.contenttypes.models import ContentType
from datetime import datetime

auto_comment = comments.models.Comment()
auto_comment.content_type = ContentType.objects.get_for_model(obj)
auto_comment.object_pk = unicode(obj.id) # I don't need force_unicode for my case, but you may.
auto_comment.user_name = 'system comment'
auto_comment.user_email = 'jawaad.mahmood@example.com'
auto_comment.user_url = 'http://it_website/'
auto_comment.submit_date = datetime.now()
auto_comment.site_id = 1 # This may be differently configured in your settings.SITE_ID file
auto_comment.save()

This should save your comment in the appropriate thread.

The life of a game designer?

Was reading EALouse and his / her comments on being let go by EA.

I deal with politics too, but holy crap, I’m guessing a steady paycheck brings a whole new world of poison. (It explains a lot actually).

Worth the read if you want to see the life of a games programmer./

See your friends’ hidden information on Mixi. – UPDATE: Not quite as bad as I thought.

This is kinda funny, but if you choose to enter profile information on mixi and then make it absolutely private (even from your friends), you can still extract it.

Go and download this bookmarklet. Save it to the bookmark bar on your browser.

Go to the page of a friend on mixi and click it. Hilarity ensues.

As far as security leaks go, it isn’t so bad since you have to friend the person before it shows up. However, I doubt that anyone is actually aware of that fact.

I love meeting people on mixi (since it is the rare avenue of socialization), but stuff like this is going to make everyone get up and leave (and that’ll suck).


For those curious about what it looks like:

Before and After using the bookmarklet.

-edit-

I’ve been doing a little more research into this and it doesn’t look as sinister as it did originally. Some of this information is hidden from the “friendship” profile screen because it is not interesting (?) after someone has already friended the person in question. It appears to be a misplaced usability optimization rather than anything else.

Installing Python2.6, mod_wsgi, and Python-MySQL on a CentOS box.

UPDATED: January 31st, 2011: Python 2.6 now is in the normal EPEL repositories. There are some changes in the explanations below

I’ve always hated Centos, probably because I’ve never been in a situation where I had to deal with the network security (other than the obvious stuff to ward off cross-site-scripting attacks and the such). Of course, that being the case, I did wind up dealing with CentOS at work and I had to get Django, Python 2.6 and the such functional.

Centos throws a few curveballs your way.. YUM is built on Python 2.4, and upgrading to a newer version supposedly breaks the program. Going back to Python 2.4 was not an option, mainly because all my python experience is on Python 2.5 / 2.6, and I don’t want to go back and learn an older non-maintained version of the language for a server. On the other hand, I didn’t want to lobby to just install Ubuntu.

This assumes you already have a normal LAMP setup. Furthermore, I’m assuming you do not have mod_python installed. This threw me for a loop for the longest time, so take this for what its worth.

The VERY FIRST STEP (if you are running a clean install of CentOS) is to get the dev tools installed.


# sudo yum groupinstall 'Development Tools'

After that, install Python 2.6 (or anything else newer in the 2.x series). As of January 31st, these are in the EPEL repositories; if you don’t have the EPEL repositories enabled, do the following:


# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
# yum repolist

Once that’s done, run yum update to get everything setup, and then install Python & the MySQL dependencies (if they aren’t already installed)


# yum install python26* mysql-devel mysql-server

This installs pretty much everything Python- & MySQL-related that you need. You will need to run the following to get an extra piece of information:


Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/usr'

The prefix (/usr) is important for later. Set it aside and finish up.


# cd ~
# wget http://sourceforge.net/projects/mysql-python/files/mysql-python/1.2.3/MySQL-python-1.2.3.tar.gz/download
# sudo tar xzvf MySQL-python-1.2.3.tar.gz
# cd MySQL-python-1.2.3*
# python26 setup.py install

(Don’t forget to create a user for use by Django in the database)


# cd ~
# wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz
# sudo tar xzvf mod_wsgi-3.3.tar.gz
# cd mod_wsgi-3.3*
# ./configure --with-python=/usr/bin/python2.6
# make
# make install

Now you need to fix up your Apache configuration. I won’t pretend to be an expert with WSGI (although I’ve managed to get it running on 3 different OSes running Apache), but make sure you include the following, somewhere near the Module block in the httpd.conf file.


WSGIPythonHome /usr/

As long as you have this setup, and a proper WSGI script, you should be able to get up and running.

The Django installation is quite easy. Go into the Django source directory and type in

# python2.6 setup.py install

That will take care of making sure Python2.6 also has access to django.

If you don’t want to install using the source code, you can also do this through pip. Follow the instructions here to install pip (while updating the version of pip to 0.8.2) and then type in

# pip install django

That’s pretty much it. I’m sure there is something unclear, but I’ve got to get back to work -_-

Email Validation in Google App Engine

My current project is building a mobile website for Japanese cellphones that can stand about 10-20k hits within an hour without getting completely trashed.  Admittedly, this isn’t exactly the easiest thing in the world to do, but Google App engine makes it a lot easier.  In the process, I had to brush up on my Python, and in particular, email validation.

The obvious way to deal with email validation is to use google’s “mail.is_email_valid” function.  Unfortunately, this seems to return true as long as you have a string, as it mentions on Aral Balkan’s helpful post on the subject.  I had to dig a little more to find out how to use mail_re; here’s the code for anyone curious.

from django.core.validators import email_re
print (email_re.match(‘test_email@fakedomain.com’) != None)
print (email_re.match(‘bademail’) != None)
Seems to work properly.