Not wanting anyone to accuse us of not running with the cool kids, I decided to implement a STOMP messaging queue system* for Fluther in November. Now, whenever a question gets asked we can offload the matching algorithm to a different machine. The result? You get a much snappier Fluther.

I’ve also rewritten our twisted-based notify server to use the message queue as well, so watch out for better emails when there’s activity on your questions.

Here’s how this afternoon went down. Many of these steps are run automatically using our custom capistrano scripts:

• Post an MOTD that the site will go down.
• Remove one of our webservers from behind perlbal, our load balancer. We use this to test our production environment later.
• Take the site down. (Disable the fluther apache site, enable the maintenance apache site)
• Using capistrano, update all of our servers with the latest messaging code (which we call lemur)
• Update all the servers with the latest fluther code
• Migrate the database (we’ve just switched over from using a home-brewed capistrano migration system to south, it’s nifty!)
• Update the new notifier codebase (we call it hydra)
• Restart all of our processes: apache, lighttpd, memcached, lemur, and hydra
• Check the logs to make sure that everything is running.
• Use our web server that we’ve taken out of the load balancer to run a few spot tests.
• Reenable the website
• Add our web server back into the load balancing pool.

In practice, there were a few snags (mostly dependency issues with the new codebase), but overall everything is running very smoothly now.

* The messaging system is a customized version of Brian Rosner’s engine library and resembles starling — it’s pluggable for different queue types, provides a nice interface for deferring functions, and has sample clients that consume messages off the queue. Let me know if this interests you!

The one thing I was really missing in vim, though, was solid code-completion feature. After much haranguing, I finally figured out how to enable omnicomplete with django.

Download and install vim for OS X

• By far the easiest way to get a version of vim that has python compiled is through macports.

  sudo port install vim +python
  

• Now replace your old version of vim in your default path (useful for when a shell command calls vim as the editor)

  sudo cp /usr/bin/vim /usr/bin/vim7.0
  sudo cp /opt/local/bin/vim /usr/bin/vim
  

• Verify that you have python compiled by typing :python print “Hello” while in vim

Enable omnicompletion

• I’ve enabled omnicomplete for a bunch of different different completers. Add these lines to your .vimrc:

  autocmd FileType python set omnifunc=pythoncomplete#Complete
  autocmd FileType javascript set omnifunc=javascriptcomplete#CompleteJS
  autocmd FileType html set omnifunc=htmlcomplete#CompleteTags
  autocmd FileType css set omnifunc=csscomplete#CompleteCSS
  

Run vim so that you can actually complete django files

• Omnicomplete imports the modules behind the scenes to help you with completion. Problem is, it won’t be able to import django.db since you don’t have a settings module specified… so any module that imports models won’t work. Not very useful.

  DJANGO_SETTINGS_FILE=myapp.settings vim
  

• Verify that imports will work by typing :python from django import db
• Now you can just press <C-X><C-O> to omnicomplete!

I also highly recommend the rope plugin for vim. It simplifies opening files within your project, and even will organize your imports! for you!

Here’s the basic rundown:

1. Get mogilefs on your box
2. Patch django to support different FileBackends
3. Get data into mogile
4. Get data out of mogile

Getting mogile

We use Ubuntu on our production boxes, and it just so happens that I’m the debian maintainer for mogile. So. Get the packages from https://edge.launchpad.net/~awmcclain/+archive (add the entries for your distro onto your source.list, run apt-get update then apt-get install mogilefsd mogstored). Setting up mogile is a little beyond this document, but check out the google group if you have any troubles.

Patch Django (optional)

I see that Marty’s work has been incoporated into Django’s 1.0 beta (congrats, Marty!), but if you’re running an older version (like we are), you’ll need to patch your codebase to support file storage backends. See the patch at http://code.djangoproject.com/ticket/5361

Install the mogile backend

Download the zip of the files and throw filestorage.py and mogilefs.py somewhere on your pythonpath. The models.py file contains some example code, as well as an urls entry. 

Set up the mogile backend

The mogile filestorage backend is fairly simple: it uses URLs (or, rather, parts of URLs) as keys into the mogile database. When the user requests a file stored by mogile (say, an avatar), the URL gets passed to a view which, using a client to the mogile tracker, retrieves the “correct” path (the path that points to the actual file data). The view will then either return the path(s) to perlbal to reproxy, or, if you’re not using perlbal to reproxy (which you should), it serves the data of the file directly from django.

In order for the backend to work, we need to add a few settings variables:

• MOGILEFS_DOMAIN: The mogile domain that files should read from/written to, e.g “production”
• MOGILEFS_TRACKERS: A list of trackers to connect to, e.g. [“foo.sample.com:7001″,“bar.sample.com:7001″]
• MOGILEFS_MEDIA_URL (optional): The prefix for URLs that point to mogile files. This is used in a similar way to MEDIA_URL, e.g. “/mogilefs/”
• SERVE_WITH_PERLBAL: Boolean that, when True, will pass the paths back in the response in the ‘X-REPROXY-URL’ header. If False, django will serve all mogile media files itself (bad idea for production, but useful if you’re testing on a setup that doesn’t have perlbal running)
• DEFAULT_FILE_STORAGE: This is the class that’s used for the backend. You’ll want to set this to “project.app.filestorage.MogileFSStorage” (or wherever you’ve installed the backend) 

Gettings files into mogile 

The great thing about file backends is that we just need to specify the backend in the model file and everything is taken care for us — all the default save() methods work correctly.

For Fluther, we have two main media types we use mogile for: avatars and thumbnails. Mogile defines “classes” that dictate how each type of file is replicated — so you can make sure you have 3 copies of the original avatar but only 1 of the thumbnail.

In order for classes to behave nicely with the backend framework, we’ve had to do a little tomfoolery. (This is something that may change in future versions of the filestorage framework).

Here’s what the models.py file looks like for the avatars:

from django.core.filestorage import storage

# TODO: Find a better way to deal with classes. Maybe a generator?
class AvatarStorage(storage.__class__):
    mogile_class = 'avatar' 

class ThumbnailStorage(storage.__class__):
    mogile_class = 'thumb'

class Avatar(models.Model):
    user = models.ForeignKey(User, null=True, blank=True)
    image = models.ImageField(storage=AvatarStorage())
    thumb = models.ImageField(storage=ThumbnailStorage())

Each of the custom storage classes defines a “class” attribute which gets passed to the mogile backend behind the scenes.  If you don’t want to worry about mogile classes, don’t need to define a custom storage engine or specify it in the field — the default should work just fine.

Serving files from mogile

 Now, all we need to do is plug in the view that serves up mogile data. Here’s what we use:

urlpatterns += patterns('',
    (r'^%s(?P<key>.*)' % settings.MOGILEFS_MEDIA_URL[1:], 'panda.main.filestorage.serve_mogilefs_file')
)

Any url beginning with the value of MOGILEFS_MEDIA_URL will get passed to our view. Since MOGILEFS_MEDIA_URL requires a leading slash (like MEDIA_URL), we strip that off and pass the rest of the url over to the view.

That’s it! Happy mogiling!

Now we’ll show you how we made a reusable paginator for different parts of Fluther.

First we had to decide how it should look, and which side would be for “Newer” and “Older”. This was surprisingly non-obvious. We thought carefully about our UI, discussed this great article by Ivan Kanevski, and came up with something we liked.

Now, how did we build it?

We wanted it to be simple and reusable, so we made a Django inclusion tag that gets called like this:

<p class="nav">
{% render_pagination %}
</p>

Inside the inclusion tag is some tricky arithmetic, but the newest version of Django provides a Paginator object, so we’ll spare you our implementation. Basically, it takes the range of pages and your current location in the list and tells you which numbers should show up–nothing too fancy.

Now the template itself is pretty straightforward:

{% if is_paginated %}
{% if has_previous %}
<a href="{{linkprefix}}page={{previous}}#browse" id="newer">&#0171; Newer</a>
{% else %}
<span id="newer">&#0171; Newer</span>
{% endif %}
<span class="pagination">
{% if more_new %}
<a href="{{linkprefix}}page=1#browse" class="first">1</a>...
{% endif %}
{% for i in page_range %}{% spaceless %}
{% ifequal i page %}
<span class="current">{{i}}</span>
{% else %}
<a href="{{linkprefix}}page={{i}}#browse"
{% if forloop.first %}class='first'{% endif %}{% if forloop.last%}class="last"{% endif %}
>{{i}}</a>
{% endifequal %}
{% endspaceless %}{% endfor %}{% if more_old %}...{% endif %}
</span>
{% if has_next %}
<a href="{{linkprefix}}page={{next}}#browse" id="older">Older &#0187;</a>
{% else %}
<span id="older">Older &#0187;</span>
{% endif %}
{% endif %}

A few things to note here:

1. linkprefix. This allows us to use the paginator on different urls without any modification. Nifty.
2. We’re assuming the #browse anchor, which isn’t the most flexible solution, but it’s sufficient for now. Eventually we’ll factor this out to be a variable.

You may be wondering, how does this actually display multiple pages? How does it all come together? Here’s where Django is a champ. The secret is using django.views.generic.list_detail.object_list. It handles everything for you. You just have to name the list in your template “yourobject_list” and render with object_list. For example, here’s how we rendered the activity page before pagination:

    return render_to_response('v2/activity.html', {'act_list':new_act,
'bookmark_list':all_act,
'account_title':"Activity You’re Following"
}, context_instance=RequestContext(request))

and here’s how we render it with pagination:

    return object_list(request, queryset=all_act, paginate_by=25,
template_object_name="activity",
template_name="v2/activity.html",
extra_context={
'new_list':new_act,
'pagelinkprefix':"/activity/?",
'account_title':"Activity You’re Following"
})

Presto! Just like that, you’re in pagination heaven:

Any other mysteries of Fluther you’d like explained? Let us know and our secrets could be yours.

In Erik’s last entry in the series, robmandu asked how we implemented the real-time chat. So, ask and ye shall receive! There are a lot of moving parts in the chat system, so I’m going to focus mostly on the back-end for this article — which allows me to show you one of my favorite parts of Django: template tags! Yeah!

Before we get started, let’s have a quick run-down of how the chat works when you visit a question on the site:

• The initial page is rendered with all the responses so-far, including anyone who might be composing currently.
• Every few seconds, you poll us to see if anyone has started writing a response, or if there are any new responses from people who have finished composing.

Fairly simple! Let’s look at how we accomplish this… but first, a little history:

Before, when we had just started the iPhone version of the site, we built each response up from scratch using DOM utilities in Javascript. That is: when your browser polled the site, you’d get back a list of usernames (and other data) from the server, then we’d hand-build each HTML element of a response and hook in the JavaScript to make the AJAXified “Great Answer” links work correctly.

Since iphone.fluther.com uses a slightly different version of displaying responses, when started making changes to this area of the code we realized that it was a nightmare to maintain. Every time we’d make a change we’d have to alter the code in four places: Twice for when the responses were rendered initially (one for each version), and twice when they were constructed in JavaScript.

Then we decided to switch to AHAH. Instead of receiving a flat list of data from the server, we now send out the fully-formed HTML which the client then places at the end of the list. We had to fudge a little on our 100% compliance with web-standards, but we scored a win on speed and most importantly, maintainability.

So, here’s how it works:

This is how we initially render our responses:

<div id="quiplist">
    {% for quip in quiplist %}
         {% render_quip quip %}
    {% endfor %}
</div>

<div id="composelist">
    {% render_composers composers %}
</div>

As you can see, not much code. Django loops through all the responses in the question and calls the render_quip template tag. Then, it renders all the composers with another template tag. Let’s see what’s in those tags:

First, render_composers.html:

{% for compose in composers %}
<div class="compose">
  <img class="avatar" src="{{compose.imageurl}}" alt="{{compose.username}}'s avatar"/>
  <p>{{compose.username}} is crafting a response&0133;</p>
  <div class="qbar">
    <span class="qspan end">
      <a href="/users/{{compose.username}}/">{{compose.username}}</a> (<span class="score">{{compose.score}}</span>
      <img width="8" height="8" class="trans-png star" alt=" points" src="/static/images/v2/star.png"/>)
    </span>
  </div>
</div>
{% endfor %}

This django template snippet takes a list of user and generates the “Crafting a response” entries.

There’s one aspect of the template tag I’m glossing over: when you call {% render_composers %}, it actually calls a python method “render_composers” which can perform any calculations you need and then pass the variables on to the template I just showed you.

Here’s the method for render_quip:

@register.inclusion_tag('v2/render_quip.html', takes_context=True)
@inherit_panda_vars
def render_quip(context, quip, ahah_format=False):

    user = context.get('user')

    marked_great = False

    if render_actions and user.is_authenticated():
        if user == quip.user:
            marked_great = True
        elif quip.quipvote_set.filter(user=user).count() > 0:
            marked_great = True

    return { "quip": quip,
             "user": user,
             "disc": context.get('disc'),
             "ahah_format": ahah_format,
             "marked_great": marked_great,
            }

Here we calculate a few things… whether we’re in AHAH mode or not (which affects how we calculate the striping of the responses), whether the user has marked this as a Great Answer! or not, etc.

Now, render_quip.html:

{% if not ahah_format %}<div id="quip{{quip.id}}" class="quip {% cycle quip1,quip2 %}
  {% avatar_img quip.user %}
    <div class="message">
      {{quip.message}}
    </div>
    <div class="qbar">

      <span class="qspan">
        <a href="{{quip.user.get_absolute_url}}">{{quip.user.username}}</a>
        (<span class="score">{{quip.user.get_profile.score}}</span>
        <img class="trans-png star" width="8" height="8" src="{{MEDIA_URL}}images/v2/star.png" alt=" points"/>)</span>
	<span class="qspan great-answer">
          {% if marked_great %}
             Great Answer!
          {% else %}
	     <a href="/usefulquip/?id={{quip.id}}">&#8220;Great Answer&#8221;</a>
          {% endif %}
        </span>
       .
       .
       .
      </span>
  </div>
{% if not ahah_format %}</div>{% endif %}

Here we see the striping I talked about (that’s what {% cycle %} does: each alternating response we render gets a different css class). We also see how the marked_great variable that we set in our python method affects the way we display our response.

So how does this all plug into the web browser?

handle_listen: function(transport) {
    var response = eval('(' + transport.responseText + ')');
    var quips = response.quips;

    if (quips.length > 0) {
        fluther_disc.since = response.lastid;

        // zebra striping
        var quiplist = YAHOO.util.Dom.getElementsByClassName("quip", "div", "quiplist"); //select only the divs
        if (quiplist.length > 0 && quiplist[quiplist.length-1].className == "quip quip1"){
             var zebra_classes = ["quip quip2", "quip quip1"];
        } else {
             var zebra_classes = ["quip quip1", "quip quip2"];
        }

        //do the building
        for (var i = 0; i < quips.length; i++){

            new Quip(quips[i].html, quips[i].id, zebra_classes[i%2]);
        }
    }

    //build the compose template
    $('composelist').innerHTML = response.compose_html;

    return response;
}

When we get into the JavaScript, we have to calculate the striping for each new response that gets added, and we just add in the HTML we got back from the server into the webpage. Now, if we need to change the format of the responses (like, say, for the iPhone) we can re-use most of our code!

Coming up next for me: Why we chose YUI over Scriptaculous and MochiKit!

Fluther uses the Django web framework, so our application code is written in Python. I just started learning Python and really like a lot of the features of the language.

One of those features is the re module, which allows you to search through text for patterns.

To automatically correct question punctuation, I first needed to detect two patterns:

1. Questions that end in multiple question marks or exclaimation points
2. Questions that end in no punctuation

Here is the regular expression I used to detect the first pattern:

MULTIPLE_PUNCTUATION_END = re.compile("[?|!]+$")

In English, this regular expression would read “a question mark or exclamation point, repeated one or more times, at the end of the string”. Note that I used re.compile, which compiles a regular expression for efficiency.

Detecting this pattern and swapping it out for a single punctuation mark can be done with just one line of code:

question = MULTIPLE_PUNCTUATION_END.sub(question[-1], question)

That was easy. My second task was to detect questions with no ending punctuation:

NO_PUNCTUATION_END = re.compile("[^(?|.|!)]$")

You would read this regular expression as “anything other than, a question mark, period, or exclaimation point, at the end of the string”.

When no punctuation is detected at the end of a question, I simply append a question mark.

if NO_PUNCTUATION_END.search(question):
    question += "?"

With just a few lines of code, I was able to pretty-up the punctuation on Fluther.

Please leave comments to let me know what you think of this new series. I wanted to start with something relatively simple, but I’d like to dig even deeper into the Fluther codebase. What are some features on Fluther where you’ve asked “How’d they do that”?