Snippet: Syslog Config for Django 1.3

After a bunch of searching and dealing with odd errors, I finally figured out how to get syslog to play nice with Django 1.3’s new logging config. I’m posting it here for my own future reference and for anybody else who might find it useful.

from logging.handlers import SysLogHandler
LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'formatters': {
        'syslog': {
            'format': 'songtrust: %(levelname)s %(module)s "%(message)s"'
        },
    },
    'handlers': {
        'syslog':{ 
            'level':'DEBUG', 
            'class': 'logging.handlers.SysLogHandler', 
            'formatter': 'syslog', 
            'facility': SysLogHandler.LOG_LOCAL2,
            'address': '/dev/log',
        },
    },
    'loggers': {
        'django.request': {
            'handlers': ['syslog'],
            'level': 'DEBUG',
            'propagate': False,
        },
    },
}

Chill The F*!% out over the Google/Verizon Proposal

In the last week or so since Google and Verizon put out their proposed legislative framework for dealing with net neutrality almost everybody has completely freaked out. I’m all for fighting to keep the internet open but a lot of what I’ve been hearing over the last week has been simply a mess of FUD, irrational screaming, and dogma. Let’s take a look at a number of the complaints that I’ve heard recently that drive me nuts…

Changes afoot at Django-NYC

Django NYCRecently Justin Lilly and I have taken up the day-to-day running of the Django-NYC users group to take some load off its original founders, Loren Davie and Kevin Fricovsky.  Loren and Kevin have done a great job of getting the group off the ground and building a community around Django in NYC.  Unfortunately, as with most user groups, running Django-NYC has become a very time consuming venture.  Accordingly they asked Justin and I to come in and help out for a while.

As part of this change of guard Justin and I have started a few new initiatives for the group to try and get more people involved.  These initiatives include recording talks, holding hack nights, providing tutorial events, and reaching out to more Django-friendly organizations around New York.

Simplest and most accessible of these initiatives is the recordings of talks from our meetings.  We now have the recordings available as a podcast (iTunes, RSS) and a Vimeo channel.  We are also experimenting with streaming the meetings live at livestream.com.

Hack Nights provide a great way for those of us with active Django projects to work in a collaborative environment.  The rules for a hack night are that you have to come with a project to work on and you will be strongly pushed to show off your work at the end of the night.  So far we've held only one hack night, but we are in the process of planning more and refining the event format.  These are great events for our more advanced members since they are able to get some work done and talk to others about their specific challenges/solutions.

Tutorials are the yin to the hack nights' yang.  They will provide a venue for new Django users to dig their teeth into Django and learn about its awesomeness.  Our first tutorial is coming up this week and we are very excited to see how it goes.

Finally we are reaching out to various Django-friendly organizations around the city to participate in all of these new events.  HUGE has been and will continue to be and excellent host and supporter of the group.  That being said, Brooklyn is kind of a pain for many potential members to get to.  Accordingly we will be moving events around the city in an effort to better engage Djangonauts from all around New York.  The first such event will be our tutorial session this week which is being hosted by Six Apart.  Additionally we are working to collaborate better with other NYC user groups, in particular NYCPython.  This December we will be holding a joint meeting and we are discussing other possible collaborative events.

So that's all of the new stuff happening with Django-NYC for now.  Stay tuned for updates on even more that we have lined up.  Have any other ideas?  Belong to an organization who would like to host an event?  Have any questions or comments?  Let me know in the comments or contact me at sean@seanoc.com.

Solango Tips and Gotchas

For the last week or so I've been wrapping my brain around Solr and Solango. The whole time that I've been doing this I've had the feeling that they can do awesome, powerful things but they're documentation is so poor that I couldn't figure anything out beyond the basic examples. Ultimately I had to dig through a bunch of code and do some experimentation. Now that I've finally figured out how to do what I've been trying to do and have wrapped my brain around some of the trickier bits I'm going to share some of the gotchas and solutions I've found.

sPaste Update

After a bit of a break, there is now a bit of new functionality in sPaste.  Now when creating a snippet users can select a date and a number of views, after which the snippet will self-destruct.  This update adds a great extra layer of security by only allowing information to exist in sPaste just as long as it needs to, and no longer.  All while keeping sPaste very simple and easy to use.

Check it out and get a copy of sPaste to run on your own server at https://spaste.com!

sPaste|source - a secure, open source, pastebin

A few months ago, I found myself with a frequent itch at work.  Often I needed to send sensitive information such as access credentials to co-workers and clients.  Obviously email isn't an acceptable way to send this information, but anything much more complex than email overly frustrates who ever I am sending information to.

My solution to this problem was to create a new site called sPaste.  sPaste is a secure pastebin where small snippets of text can be easily submitted, secured, and sent to other people.

At a personal level, sPaste was great success.  sPaste took me less than 40 hours to write (thanks to the magic of Django and jQuery) and it perfectly meet my needs.  Unfortunately in its existing form, it could never really be useful to most other people.  Since sPaste is running on my server, anybody using sPaste would have to trust that I'm not doing anything evil with their data.  Accordingly, for the past couple of weeks I've been working on cleaning things up and putting together an open source release.

Today I finally finished that work and have released sPaste|source.  sPaste|source is a ready to go site, based on Django, which gives all of the features an functionality of sPaste.com on your own server.  Simply grab the source, set it up like any other full Django project, and you will be ready to go.

Check it out!  Feedback and comments are always welcome.

Quick Django Trick

Recently while playing around with a Django model in the always awesome iPython shell I discoved a neat feature of the Django ORM.  It's basically a way to get the id of a related object without actually triggering a query to get all of the related object's data.


Frequently when working with a model which has a foreign key, I simply want to access the id of the related item and I don't care about any of the related item's other information.  Situations where this comes up include generating links and building queryset filters.  Unfortunately if I follow the normal Django style and do something like "item.related.id", the Django ORM will fire off an extra query to get all of the information of the related object (which I don't care about).  While this is far from tragic it is still unnecessary work since all I care about is the object's id and that is already contained in the "item" object.


Fortunately there is an alternative!  Instead of getting the id via "item.related.id" one can say "item.related_id".  Using this method, no extra query is performed and I get just the id value I was looking for.


There are two things to be aware of with this trick.  First I have not found this feature documented anywhere with a cursory search of the Django docs.  This means that I am not sure how much this feature is actually supported and how permament it may or may not be.  Second while I have not tested it, I suspect that if your foreign key has a custom database field name, the field on the model will match that custom field name.


As I come across any other quick Django tricks I may start making them a regular feature here on the blog.  If you found this intersting or have your own quick django trick, let me know and leave a comment!

Annoucning sPaste.com

Tonight I am officially launching my new side project,  sPaste.com!  sPaste is a simple tool to help you quickly and securely send small snippets of data around the web.  As usual, the site is written entirely in Django on the server side and jQuery on the client side.  At the moment it is little more than a pastebin which forces the use of SSL but soon it will offer additional features and tools.

Check it out at https://sPaste.com and let me know what you think!

Update to django-ae-utils

I've been hanging out at the NYC App Engine Hackathon today and I've had some time to work on django-ae-utils.  Accordingly I've just posted an update to django-ae-utils.  This update includes a User model which uses the App Engine datastore as a backend, as well as a few generic views for working with the model.

Check it out at Google Code!

Introducing django-ae-utils

Recently I've started to play around with using Django on Google's new App Engine.  As mentioned by many others at this point, Django technically runs on App Engine but there are significant parts which do not.  Accordingly I've started to write some code to replace or supplement the holes left in Django by App Engine.  Since I figure this code may be of use to others I've released it as an open-source project called django-ae-utils (github mirror coming soon).

Google Launches App Engine

Google just launched a new platform called App Engine.  Basically it allows you to run your web application on Google's servers using much of their main infrastructure such as BigTable and GFS.  The best part is, you write App Engine apps in Python and they include Django out of the box!  Mike Arrington has a video of Guido Van Rossum talking at the launch event as well as a pretty good summary at TechCrunch.

It should be very interesting to see what this platform can do and how people will put it to use.

Working around MySQL's horrible "ORDER BY rand()" in Django

Recently I've been working on a web 2.0ish community site written in Django. As is frequently the case with such sites I often need to create lists or collections of psuedo-randomly selected items. For example on a user's profile page there may be a box showing a few of the user's friends, another box with some of the user's
pictures, or a box with random comments the user has made.

Ideally in this type of situation I would simply preform a query with what ever rules I need and a random "order by" statement such as the following:
pictures = User.picture_set.filter(private=False).order_by('?')[:6]

Which generates SQL similar to:
SELECT * FROM `pictures`
WHERE private = 0 AND user_id = 5
ORDER BY rand()
LIMIT 6

In an ideal world this works great, I only get back as much data as I need and the site stays interesting because what the user sees is constantly changing/rotating. Unfortunately unless you are using PostgreSQL or have less than a few hundred rows in the pictures table you are not in an ideal world. Under both MySQL 4 and 5 random ordering is horrifyingly inefficient. Adding that "ORDER BY rand()" can make a query that took a few milliseconds to run instead take tens of seconds. The problem gets even worse when you are working with a table containing millions of rows and thousands of rows which meet the criteria of your query. What is one to do?