Archive for the ‘TurboGears’ Category

Caching Aggregated News Feeds

Saturday, October 13th, 2007

Did some work on becontrary.com today. The front page was a little dull and had a bounce rate of 49.8% according to Google Analytics, which means that almost half of the visitors that land there don’t go any further. Previously the front page just displayed a news feed and some recent arguments and comments, I change it so that the feed in the main column aggregates the content from the debates so that in addition to news, it also displays new debate topics and arguments. The result is that it the front page should contain much more interesting content that will tempt visitors to explore the site.

I also made the BeContrary aggregated content available as an RSS feed, which makes it very easy for me to keep an eye on activity in the site. Hopefully it should be entertaining for visitors as well. Turbogears makes it laughably simple to add news feeds with the FeedController class. You simply derive from it and supply a method that returns the feed content. The controller does the work of producing the XML and serving it with CherryPy.

Because the changes would increase database access, I wrote a caching decorator for methods that return site content which doesn’t need to update very often. If the decorated method is called within a definable period of time, the decorator returns a cached copy of the return value rather than building it again. Using this decorator I was able to reduce the database calls for the front page to zero for most requests (it updates every half an hour). This should come in handy if I get Slashdotted, Reddited or Dugg. Come to think of it, I could use the cache decorator on most of the site content. Even if the cache time was set to one minute it would be worthwhile for serious traffic. If I were to get 10 requests in a minute, it would reduce database access to one tenth! I’ll probably blog the decorator at some point.

I seem to be finding a lot of time for my blog and hobby projects lately, because my TV broke! Rest in peace, my widescreen friend.

Update: I blogged the decorator code.

Convince Me to Be Contrary

Wednesday, October 10th, 2007

I just came across a site that is remarkably similar in concept to becontrary.com, called convinceme.net. I don’t think it existed when I started work on my site. Like becontrary.com, they have dual columns for arguments and voting, but it is more competitive than my debating concept, which about arguing purely for the hell of it. They also have a slicker looking design, obviously created by a real web designer rather than a coder working on it in his living room. Oh well. I guess competition isn’t necessarily a bad thing!

Being Contrary with Turbogears

Saturday, October 6th, 2007

I promised to write up a report on my experiences building becontrary.com with Python and the TurboGears framework. An earlier post explains the concept of the site, and what it is intended for.

I wanted to use Python to build a site, rather than something like php because Python has always made me significantly more productive as a programmer, and frankly because I am a huge Python fan-boy. Before I started on ‘debate site’, as I called it then, I dithered over which of the frameworks to use. The two major contenders at the time were Turbogears and Django, although I did consider other Python frameworks, and even Ruby on Rails. I was swayed towards Turbogears because it uses CherryPy, which I had had used previously and found ridiculously easy to use. To be honest though, my choice of framework was fairly arbitrary, but I do tend to suffer from analysis paralysis and I needed to make a decision. Ultimately I suspect that the choice of framework is less important than it may appear to be.

Turbogears was designed with the Model View Controller (MVC) paradigm in mind, which separates the web application in to three logically separate components. The Model is the database, the View is how the database information is presented and the Controller is the code that manulates the database. Its a well-established pattern that works well for web apps.

Getting Started

Getting started with Turbogears is a breeze. The command line interface takes a few parameters and generates a working application for you, which is very encouraging. Unfortunately I ran in to a few bugs very early on, and they weren’t insignificant bugs either, they were kind of show-stoppers at the time. Fortunately help was to be found on the mailing list and I was able to work around them. I can’t even remember what they were now, and I imagine they were fixed a long time ago.

The Model

One of the major attractions of a Python framework is that it can hide the details of working with a database behind an Object Relational Mapper which enables you to work with the database as if it were a collection of Python objects. Or at least it tries to. I found that SQLObject, the ORM used by Turbgears, didn’t create a perfect abstraction and to get the best out of it I needed to understand what was going on behind the magic. For the majority of tasks though, SQLObject made it trivial to work with the database.

Incidently, I don’t like the way that Python ORMs specify the database schema as Python code. Since the schema doesn’t change when the application is running, I would prefer a simple xml definition that would be used by the ORM to dynamically build classes for each table that could be derived from in the model code. That way the schema definition could be ORM independant and also kept separate from the code that manipulates it. Perhaps I’m not seeing the big picture, having never tacked writing a database layer.

The View

Turbogears uses Kid templates, which are basicaly XHTML files with additional tags that are processed with Python to generate viewable output. I really didn’t like the idea of hand editing XML to generate content, and I had intended to create the templates with Dreamweaver. However, I found that with a good XML editor it was not quite as error-prone as I had expeced. The Kid language is very expressive and I didn’t find any limitations in the design, but I was frustrated by the fact that mistakes in the template didn’t generate useful error messages. This one issue lead me to switch to Genshi, which is similar to Kid but gave far more specific error messages. The translation was painless and with experience I became very adept at writing the templates.

Although templates are considered the View component of the framework, I found that the CSS code deserved that title more than Genshi because I could generate very simple XHTML content with templates, and make it look nice with CSS. This made me feel a little better about occasionaly abusing the MVC purity by including code snippets in the templates. Practicality beats purity, right?

The Controller

CherryPy maps HTTP requests on to methods of a controller class, which makes handling the functionality for requests as simple as writing Python code. Most of the methods simply validated some parameters and pulled a few entries from the database. Even complex pages only required a few pages of code. This surprised me actualy, because the majority of the work was not Python, it was in the templates and CSS.

AJAX

I used AJAX in several places, to make the application seem more responsive. Creating an account for example. Such pages are usual tedious and error prone and, as a user, I often give up. I hate it when mistakes in the form throw you back to the same form, but the contents aren’t as you left it (e.g passwords fields are blank). The account creation form in BeContrary.com is a single page and you get feedback from errors quickly.

The only place where AJAX was essential was in the voting. The arguments to each debate can be given a vote between -2 and +2. If the user had to wait for a page refresh when voting it would be a tedious process, and not to mention taxing on the server. As it is, a tiny AJAX request is sent for each vote that updates the server. The controller handles AJAX requests in the same way as other pages, which made the server part of the system nice and simple.

Technically though, I didn’t use AJAX because I didn’t use XML to return information. I didn’t even use JSON, because for most things all I needed was an ‘ok’ or a ‘fail’ message.

Conclusion

Its was a great hobby project. Once I had gotten over the initial learning curve, not just of Turbgears but of CSS and AJAX, then I became remarkably productive. I found that I could sit down for an hour (sometimes less) and implement a new feature. The quick turnaround of new features gave me the impetuous to finish it. Something that is far from certain with my hobby projects!

Deployment

I considered the hosts shown on the Turbogears website, but settled on webfaction.com. They are very dynamic language oriented and offer a competitive deal. The site has been up for a few weeks without a hitch.

Promotion

Now I need to think about promoting the site. Something which I have never been particularily good at. I tried a bit of shameless self promotion, but I never get any love from Reddit with self-submitted links. Typically anything I submit gets voted down immediately without a single referer showing up in my logs. *sigh*

Be difficult. Be compelling. But above all—be contrary.

Saturday, September 29th, 2007

I had a marvelous idea for a website that combines fairly traditional elements from web applications like bulletin boards with elements from Web2.0 sites. I mulled it over for a while, and explained it to a few people—who seemed to like the idea.

The idea is for what I call recreational debating, i.e arguing for the hell of it. A debate consists of a topic of discussion that has two clearly opposing sides, represented by two columns were users can post their arguments. Users can comment on these arguments and also rate them on a scale between -2 and +2, a scheme that Pythonistas will be familiar with. Arguments are ranked according to votes given, so the best argument for each side will naturally rise to the top.

That was over a year ago, I have been hacking away at it since then. I haven’t had a great deal of time of to do it, having also written a book in that period, but I managed to deploy it last weekend. I call it BeContrary.com, because users are encouraged to post on both sides of the argument, regardless of what they believe in.

Be Contrary

I plan on posting on my experiences creating the site (it was built with Turbogears), but for now I would really appreciate some feedback on the site itself. It has been up for a week, and I have discovered no obvious flaws (which makes me nervous)!

Telepods of Doom

Tuesday, September 25th, 2007

It is the year 2112. Telepods have been in use for a decade to instantly transport matter from one part of the universe to another. You are waiting in line with your family at a telepod station to go to Tau Ceti. In front of you in the queue you meet the inventor of the telepods. He tells you that the telepods only appear to move matter, what they actualy do is create an exact duplicate at the destination and destroy the original in the process.

Do you get in the telepod?


Close
E-mail It
Socialized through Gregarious 42