created 06 January 2010 in links tagged django, english and language.
To summarise: if I were you, I would give up now.
Luke Plant on English. Good advice.
http://groups.google.com/group/django-developers/msg/2e92...
created 23 September 2009 in links tagged django and mailinglist.
I want to drive home the point that Earth is a very large place, and no matter where you are located, most of the world’s population isn’t anywhere near you - and no amount of technology will fix problems caused by the laws of physics
http://groups.google.com/group/django-developers/msg/f939...
created 28 May 2009 in notes tagged django, hosting, passenger, python, rails, ruby and sysadmin.
I like writing small self-contained applications, and I like writing then using nice high-level application frameworks like Django and Rails. Alas, I also like being able to run these services for the foreseeable future, and that’s a lot harder than writing them is. Running a single Rails or Django application consumes an appreciable chunk of the memory on my tiny colo, and I currently have about 5 projects I really want running all the time (this could easily grow to 50 if I had a sufficiently good way of hosting them). Ideally, I’d never stop hosting these things. Otherwise what’s the point?
It’s sometimes tempting to just write all my toys in PHP. I’m certain that PHP has the mind-share that it does primarily because it’s so incredibly easy to deploy. Ease of development is utterly trumped by ease of deployment for anything not written for internal use only for a large company. tar is easier to use than mongrel, so there are more deployed PHP apps than Rails apps. But I’m not that desperate. I like my nice frameworks.
I tried Heroku as an external host for my apps for a bit, and it’s great. Very easy to start things, very easy to leave them up, and the free hosting plan is perfectly adequate for your average web application. Alas, there are a couple of raw edges that only really became apparent after using them for a few weeks. Firstly, they want to charge me for using custom domains, and I’m not willing to park my apps on domains that don’t belong to me. Secondly, their service goes through odd periods of 500 errors. This doesn’t bother me - what does bother me is that there is no official reaction to any of the complaints about it on what seems to be the official mailing list. Finally, quite a lot of the things I do need cron scripts, for polling services, etc, and the heroku crons (a) aren’t very reliable that I’ve found, and (b) cost money. So I’m edging away from them recently. Would still recommend them for prototyping, not sure I’d want to host anything Real there just yet.
(An aside - I’m not unwilling to pay any money at all. I will happily pay money for things that matter. But these apps are toys. The average number of users they have is ‘1’. I’m not willing to pay a fiver a month per application to be able to host them on my domain rather than Heroku’s domain. A fiver a month for all of them at once? Sure. But the Heroku payment model assumes that you have a small number of apps that you care about, rather than a large number of apps that you don’t.)
Anyway, my current attempt at solving this problem is Phusion Passenger (via mattb), which does exactly what I want, for Rails apps. It’s an Apache 2 or nginx module, and it’s trivially easy to install, unless you’re using Debian, which I am. Short verison? It was a lot easier to totally ignore the debian packaging system except to install ruby, then build rubygems and everything else I needed from source. Sigh. I understand there are horrible philosophical differences underlying this pain. But it’s still pain.
Once installed, you can just point your domain’s DocumentRoot at a Rails app’s ‘public’ folder, and the Right Thing happens - files in public are served directly, other requests will cause a rails process to be started, and serve your app. Enough idle time, and it’ll shut down again. Magic. My favourite part is that it’ll start up the application server as the user who owns the ‘environment.rb’ file of your application, meaning that your app is running as your user, and can do things like write files into temp folders that don’t need sudo to be able to delete again.
Not all of my projects are Rails apps, though. jerakeen.org is a Django app, for instance (this week, anyway). Unexpectedly, it turns out that Passenger will do the same thing for Django apps, though it’s not as well documented. I have a file called passenger_wsgi.py in the root folder of my Django application folder. It looks something like this (if you use this, you’ll need to change the settings module name):
import sys, os
current_dir = os.path.dirname( os.path.abspath( __file__ ) )
sys.path.append( current_dir )
os.environ['DJANGO_SETTINGS_MODULE'] = 'mydjango.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
And in my Apache config file, I have this:
<VirtualHost *:80>
ServerName jerakeen.org
...
DocumentRoot /home/tomi/web/jerakeen.org
PassengerAppRoot /home/tomi/svn/Projects/mydjango
and thus are all my toy projects now brought up and down on demand. I’m happy again. Till next week, probably. ONWARDS.
created 24 March 2009 in links tagged django and googleappengine.
AppScale is an open-source implementation of the Google AppEngine (GAE) cloud computing interface
Here’s another way of avoiding lock-in - reproduce the entire GAE environment outside of Google. Probably the best long-term solution, especially if you want the ability to host something big yourself.
created 23 March 2009 in links tagged django, heroku and mediatemple.
Other things I have found while looking for Heroku-equivalents for Django - MediaTemple do a ‘GridContainer’ that seems very similar. I wonder if I can try it out without paying any money..
http://mediatemple.net/webhosting/gs/features/containers....
created 23 March 2009 in links tagged django and heroku.
I love Heroku. Must write this up. But, despite the goodness that is Rails 2.3, I still really like Django. I want a Heroku for Django. Looking for it, I found this piece.
The Django and Python classes would have sat empty for months or years as we put our energy into developing for Ruby and Rails
Here’s someone who’s over-engineered things and been bitten by it. Hurrah for the voice of experience. But it’s still a pity that they won’t be supporting Django any time soon..
http://adam.blog.heroku.com/past/2008/5/8/dont_build_the_...
created 23 March 2009 in links tagged developer, django and googleappengine.
gae2django is a Django helper application that provides an implementation of Google’s App Engine API based on pure Django.
The helper makes it easier to re-use applications originally designed for Google’s App Engine environment in a Django environment.
via swillison. Might solve one of the annoying lock-in problems that GAE suffers from - you can’t leave - and it’s a cleverer solution to my mind than trying to make the google object store look like a traditional database.
created 15 September 2008 in links tagged django, packaging and python.
A nice summary of python packaging things, on the django-developers mailing list.
http://groups.google.com/group/django-developers/msg/5407...
created 15 August 2008 in links tagged django, mailinglist and opinionated.
One thing we don’t want to get into is a situation common in more “modular” systems where introductory documentation ends with “Congratulations on getting the base system installed; here’s a list of five hundred components you can use, go pick the one you want because we refuse to take a stance on it.”
http://groups.google.com/group/django-developers/msg/4db5...
created 15 August 2008 in links tagged detector, django, middleware and mobile.
Middleware to sniff for mobile user-agents. Yay, now I can throw away another chunk of hand-rolled code.
created 30 May 2007 in links tagged django, filter, markup and smartquotes.
django filters to do nice text markup. Shiny.
created 30 May 2007 in blog tagged django, google and python.
I’ve moved the DjangoKit source and documentation (such as it is) into Google Code at the request of Rob Hudson, so other people can work on it. Other people? Work on my code? Crazy.
created 29 March 2007 in links tagged deployment, development, django and python.
Good musings, including some non-obvious stuff that really should be documented better. Keeping apps out of the project tree is a really good idea.
http://www.b-list.org/weblog/2007/03/27/reusable-django-apps
created 28 March 2007 in code tagged cocoa, django, macos and python.
DjangoKit is a framework that will take a Django application, and turn it into a stand-alone MacOS application with a local database and media files. It started as more of a thought experiment than an effort at producing a real application, but I have it working, and you can package perfectly usable stand-alone applications with it.
DjangoKit is currently hosted in a Google Code repository, so go there for downloads and source, or just get the svn tree directly at http://djangokit.googlecode.com/svn/trunk/.
created 25 September 2006 in links tagged django, python, recursion and templating.
Using template tags to do recursion in templates
http://groups.google.com/group/django-users/browse_thread...
created 25 September 2006 in links tagged django, python and templating.
django is 90% wonderful, and the 10% that sucks is all in the templating system. So annoying.
http://jjinux.blogspot.com/2006/02/python-recursion-in-dj...
![Django | Code | #1849 ([patch] Collapse consecutive hyphens in slug fields)](http://jerakeen.org/files/thumbnail/url/65836e2feb763e86b120f4f72afed922_240x180.png "Django | Code | #1849 ([patch] Collapse consecutive hyphens in slug fields)")
created 09 May 2006 in links tagged cms, comments and django.
An example of using the built-in django comments management stuff. Which I don’t use, but only because I didn’t know about it. Now I do.
http://www.rossp.org/blog/2006/feb/17/building-blog-djang...
created 22 November 2005 in links tagged catalyst, django, frameworks, meeting, pub, rail, ruby and turbogears.
There are a scary number of frameworks represented here. Must go.
http://www.brunningonline.net/simon/blog/archives/001961....
