By some measures, Django is still shiny and new. Originally created in 2003, it's newer than my car. A house built that year would be considered pretty much fresh from the oven. A baby born in '03 would be just entering sixth grade now. But by Internet time, it's been around practically forever. Especially because Django has been under constant development for that whole time.

The fundamental concepts and philosophy of Django have not changed much, but there have been significant features added and modifications made to the way many components work. This is especially noticeable to those of us who have been using it since its early beta days. While I didn't agree with every change as it was made (auto-escaping in templates, for example), in general Django has clearly been getting steadily better.

(more...)

Don't mix user-uploaded content with site-specific content with Django admin content.

This is a simple one, but I have seen projects where this was not followed, and the result was a real mess. so please, please, please do not mix your media!

There are (at least) three types of content that we can think of as "media" in a Django project: There is the Django admin media - the CSS files, images, and JavaScript that come with Django itself for use in the admin interface. Then there is your own static media that you use to style your site. And finally, there is user-uploaded content - things like profile pictures and so on. I recently took over a project where all three were in the same directory. I nearly wept.

(more...)

This is the second in my series that I am calling "Eddie's Practices" for Django, in which I present tips and tricks that I have gleaned over the years of working with the Django web application framework. If you haven’t seen Eddie’s Django Tip #1: Choose Names Carefully, why not take a look at it now?

Today's tip is:

Don't Get Trapped in the Django Universe

One of Django's strengths is its "batteries included" approach. It provides for free many of the features you would normally have to write from scratch or cobble together from disparate sources. Some examples are the authentication system, the administrative interface, and the templating system. These are wonderfully useful, and they often work together in ways that separately developed libraries can not. However, not every part of Django will fit your needs all the time. Choices were made in the design of Django, and those aren’t always the same choices you would have made.

Fortunately, another strength of Django is its modularity. It is very easy to unplug one of its built-in features and plug in your own or someone else's. I'll go through some of the Django features that you may want to consider replacing or eliminating.

The important point I want to emphasize is that there is nothing unclean or dangerous about doing this. It's your site, you're the boss of Django, and you should only use the parts of it that you need. I think the creators of Django would agree with me.

(more...)

Why "Eddie's Practices?"

Django has become one of the more popular web frameworks out there. I have been lucky enough to have worked with it for many years, starting in its early beta stages. I've used it to create many web applications on my own, and I've worked on many apps that were originally created by others.

As in most development environments, there are certain common issues that pop up again and again. Over the years, through trial and error, talking to other developers, and a lot of hard thinking, I've come up with some general approaches to many of these issues.

I have gotten a great response to my previous posts about Django, so I decided to create a new series of posts, dealing with these tips and techniques. I wouldn't have the hubris to call these "best practices," because that would imply that my way is best for all developers. So I'll just go with "Eddie's Practices." These are things that work for me, things I wish people had told me when I was starting out. I hope they work for you, too. Mileage may vary, as they say.

Tip #1: Think hard about what to name your project and your app.

We'll start with a basic one, but one that seems to come up over and over. When you get started with Django, you create a "project," and then within that project you create an "app." You need to come up with names for both of them. This may seem a trivial point - surely an app by any other name would be just as enterprisy. But it can affect your future development in unexpected ways. (more...)

I have previously written about the Scopa game I developed for Facebook. Well, I became frustrated with the technical limitations of the Facebook canvas platform, and decided to move it off of Facebook onto its own site. So now you can practice your Italian and learn a new card game at www.playscopa.com. You can still log in with your Facebook account, though.

If you’ve never heard of Scopa, it’s a fun Italian card game for two or more people. You can play with one of two gorgeous Italian decks of cards or a standard American deck with the face cards removed. There is a section on the site where you can learn how to play Scopa as well. You can practice by playing against the computer, and the game also has a “beginner” level where the computer will give you hints about what moves you can make next.

For my technical audience, the site is implemented in Python and Django on the back end. The game play is completely handled in HTML and JavaScript, using the Comet technology for real-time player-to-player communication. The back end server is my custom-built Sully Server (soon to be released as open-source).

Enjoy, and go play Scopa!

After many months of hard work, I'm proud to announce that my new poker site, Best Texas Hold'em, is now up and ready for a Beta test. You can play now at www.bettorbest.com.

It's still in its early stages, but gameplay is working. You can log in with a Yahoo, MySpace, or Hotmail account, or your email address (Facebook support coming soon).

Since it's brand new, there may not be anybody to play against right away, so you may have to check back, or better yet invite a friend, if there is nobody there. Soon enough there will be artificial intelligence support to fill in when necessary.

For the technically interested, the site is programmed in the Python programming language using the Django web framework, and hosted on a Slicehost server. The front end is pure JavaScript with no downloads or plugins required.

Give it a try if you get a chance, and please let me know if you find any
problems.
Thanks!

Welcome to the third part in my series of posts about creating a Facebook application. I am using Django as my web development framework, and this post will focus on some of the backend techniques I have worked out to make this work easier. This is not a tutorial, but a set of tools that I have developed. This is a long post, with a lot of source code; I hope you find at least some of it useful.

Keep in mind as you read this that the Facebook platform is still very new, and likely to change. In fact, if you're a FB user, you are probably aware they recently completed a major transition to a new profile design. This included many changes behind the scenes for developers, some of which are still playing out. I recommend keeping up with the Facebook Platform Developer Forum and the Facebook Developer Blog.

Also, I will assume you have already read the API Documentation and the documentation for PyFacebook, and that you know how to create a web app using Django. If not, you will want to start there.

(more...)

Welcome to the second part in my series of posts about creating a Facebook application. I am using Django as my web development framework, but this post doesn't have much to do with Django, since it deals with the front end. In particular, it talks about how to write JavaScript that can work both in and out of Facebook.

As I mentioned last time, Facebook lets developers use a subset of JavaScript, which they call FBJS. The FBJS is transformed on the fly into JavaScript as the page is loaded. All variables and functions you define or reference are prepended with a string like "a123456789_", including calls to document.getElementById and setTimer and the like. This is done in order to restrict what you can do with DOM elements, to avoid cross-site-scripting attacks and unwanted user-hostile behavior. FBJS is fairly well documented, so if you plan to do some Facebook JavaScript development, you should start there.

The biggest restriction that FBJS imposes is that you can no longer access the attributes of DOM elements directly, but must go through an abstraction API consisting of a series of setters and getters. For example, instead of saying something like imageEl.src = myImageUrl, you instead need to call imageEl.setSrc(myImageUrl).

(more...)

Facebook made a splash a year or two ago when they opened up their API. Now developers could write applications that integrate with the site. Instantly, users -- many of whom had fled to Facebook from a spam-filled MySpace -- were inundated with Requests to battle ninjas and News Items bearing obscene pictures. To Facebook's credit, they did clamp down and put some restrictions on what apps can do. A few entertaining or useful applications have risen to the top, and the potential of the API is ready to be exploited. It's not an easy task for a developer, however. In the next few Chicken Scratches posts, I'll talk about my experience developing two Facebook apps from scratch: The Limerick Book, a site that works both in and outside of Facebook and allows users to share and rate Limericks, and Play Scopa, a traditional Italian card game that users can play against each other in realtime (this one is not yet launched to the public). This first post discusses some of the difficulties I have run into. In the next couple posts, I'll discuss how I dealt with them. First, to set the scene:

My setup

I am using the Django web framework for my backend development, the latest SVN version running with Python version 2.4 on a shared host at Dreamhost. In fact, it's the same server I use for this site and weblog. To connect Django to Facebook, I am using the nice PyFacebook library, which is pretty mature, though I had to modify the code to support some of the latest features of the Facebook API. And now, on to the perils. (more...)

I have written two previous articles about how I edit Django template files in Emacs and XEmacs. Here is How I edit Django templates. And here is More on editing Django templates in XEmacs. Here today is another little tip that can be used in conjunction with those two other posts or independently.

Django templates involve a lot of punctuation. Between the angle brackets and slashes of HTML and the curly braces and percent signs of the Django template language, it's enough to make your pinky fingers hurt just thinking about it. Therefore any little trick to reduce some of this typing burden can be helpful. Presented here is some Emacs Lisp code to provide auto-closing of Django template tags. So even if you still have to type things like curly-brace percent-sign space ifequal blah blah2 percent-sign close-curly-brace, you won't have to type the {% endifequal %}. (Of course, if you're using the abbrev tips I gave previously, you won't even need to type the opening tag very often, but sometimes you still do.)

(more...)