Dream Geodjango Server Setup - Step-by-Step Instructions
Here's how I've gone from a brand new slicehost slice to dreamy geodjango server. Cribbed heavily from other setup tutorials, this collects a bunch of disparate information into one place. Stack includes nginx frontend, cmemcache, apache/modwsgi, and postgres 8.3. http://wiki.slicehost.com/doku.php?id=dream_geodjango_server I plan on improving these docs over the next several days and need help in one area - namely, there is something wrong with the compilation of some of the geo dependancies. This has worked on slicehost ubuntu slices until about this week, now one of the libraries is inexplicably being compiled as 32 bit. Any help on this would be greatly appreciated. Hope that this helps some folks get started with geodjango! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Dream Geodjango Server Setup - Step-by-Step Instructions
I think generally I'm less interested in scaling per-se with this than the ability to host multiple django sites on a single server without running out of RAM / CPU. VPS hosting, essentially. On Oct 1, 4:24 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Not with geodjango directly, but I'm intersted by the choices you made > regarding the stack. > > I'm actually hosting our project on Amazon EC2 (Fedora) and I'm > evaluating scalr.net (Ubuntu) to provide a full redundoncy/scalable > architecture to our project. > > We are serving our static from S3, but we plan to use another CDN > (probably the Amazon one), once it will be publicly available. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Question about ornery nginx reverse proxy in front of apache mod_wsgi
Just to follow up on this, my problem appears to have been a munged install of nginx. I restarted from scratch with the exact same config files quoted above and it just worked™ So the settings files I quoted above appear to be OK, in case anyone wants to crib off of them. On Sep 27, 9:29 am, [EMAIL PROTECTED] wrote: > On Sep 25, 2008, at 9:23 PM, Prairie Dogg wrote: > > > > > I'm trying to set up a new server to host several existing django > > sites. The stack is: > > > Ubuntu Hardy Heron > > Apache 2.2 MPM Worker w/ mod_wsgi (for dynamic content) > > Nginx (for static files) > > > I'm migrating away from mod_python. The django apps run correctly > > under apache mod_wsgi - I've tested this by running the sites under > > Apache directly on port 80, everything works swimmingly. > > > Then, I put up an nginx instance to reverse proxy the dynamic content > > and serve static files directly. nginx serves the static files > > correctly, but the dynamic content hangs indefinitely, eventually > > throwing a 504 timeout error to the browser and leaving this message > > in the nginx error log: > > > 2008/09/26 00:38:05 [error] 3544#0: *10 upstream timed out (110: > > Connection timed out) while connecting to upstream, client: > > 198.28.57.218, server: mysite.com, URL: "/whatever/53/", upstream: > > "http://127.0.0.1:8080/whatever/53/";, host: "mysite.com" > > > I'm using the exact same nginx virtualhost config as I did under > > mod_python. Am I wrong to assume that this should Just Work™? Has > > anyone else experienced this problem when moving from mod_python to > > mod_wsgi? Any suggestions on what might be going wrong here? > > I'm running the same stack with no problems. The only difference I > could see in our configurations was that I'm using mod_wsgi in daemon > mode. I'm using mod_wsgi 2.3 and nginx 0.6.32; which do you have? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Using mod_python with Lighttpd - advice on the best set up
Conventional wisdom is that mod_python eats a little more memory than a correctly configured mod_wsgi. Here are some nice posts about using mod_wsgi in low memory environments: http://groups.google.com/group/modwsgi/browse_thread/thread/d21c334972fc8d37 http://www.technobabble.dk/2008/aug/25/django-mod-wsgi-perfect-match/ Another bit of conventional wisdom is that nginx > lighttpd because of a memory leak in lighttpd, but my favorite endorsement of nginx was Will Larson's. He chose nginx because it was Russian and "therefore exotic": http://lethain.com/entry/2007/jul/17/dreamier-dream-server-nginx/ That, by the way was a blog post that helped me get my production servers up about a year ago using one of the techniques you were asking about called "reverse proxying" where requests for static media are handled up-front by a lightweight server and all other requests are sent through to apache / mod_whatever for the heavy lifting. On Sep 29, 1:37 pm, Kip Parker <[EMAIL PROTECTED]> wrote: > Thanks Frank, that's very interesting. A lack of complaining users is > much to be desired. Have you ever used this set up for multiple sites? > I have about 20 sites running, and there may well be more in the > future. > > It would be excellent also to know what you found painful about > mod_python. > > All the best, > > Kip. > > On Sep 29, 6:23 pm, Frantisek Malina <[EMAIL PROTECTED]> wrote: > > > I wrote a post for you on my > > blog:http://vizualbod.com/articles/nginx-fastcgiwsgi-django-deployment > > > I've tried mod_python and it was a pain. > > > Frankhttp://vizualbod.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Question about ornery nginx reverse proxy in front of apache mod_wsgi
I'm trying to set up a new server to host several existing django
sites. The stack is:
Ubuntu Hardy Heron
Apache 2.2 MPM Worker w/ mod_wsgi (for dynamic content)
Nginx (for static files)
I'm migrating away from mod_python. The django apps run correctly
under apache mod_wsgi - I've tested this by running the sites under
Apache directly on port 80, everything works swimmingly.
Then, I put up an nginx instance to reverse proxy the dynamic content
and serve static files directly. nginx serves the static files
correctly, but the dynamic content hangs indefinitely, eventually
throwing a 504 timeout error to the browser and leaving this message
in the nginx error log:
2008/09/26 00:38:05 [error] 3544#0: *10 upstream timed out (110:
Connection timed out) while connecting to upstream, client:
198.28.57.218, server: mysite.com, URL: "/whatever/53/", upstream:
"http://127.0.0.1:8080/whatever/53/";, host: "mysite.com"
I'm using the exact same nginx virtualhost config as I did under
mod_python. Am I wrong to assume that this should Just Work™? Has
anyone else experienced this problem when moving from mod_python to
mod_wsgi? Any suggestions on what might be going wrong here?
I feel as if I've ruled out the "usual suspects" of file permissions
and path errors because dynamic content works perfectly under apache
(apache port 8080 while running nginx works as well!) But the
requests for dynamic content via nginx port 80 always time out.
Any help would be greatly, greatly appreciated.
Here are my config files:
--- apache.wsgi ---
import os, sys
apache_configuration= os.path.dirname(__file__)
project = os.path.dirname(apache_configuration)
workspace = os.path.dirname(project)
sys.path.append(workspace)
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
--- Apache vhost file ---
ServerName mysite.com
ServerAdmin [EMAIL PROTECTED]
WSGIScriptAlias / /home/django/django-sites/mysite.com/mysite/
apache/apache.wsgi
Order deny,allow
Allow from all
# Log files in custom directory /var/log/apache2/vhosts
LogLevel debug
ErrorLog /var/log/apache2/mysite.com/error.log
CustomLog /var/log/apache2/mysite.com/access.log combined
--- nginx vhost file ---
server {
listen 80;
server_name mysite.com;
# Main location
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP$remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size64k;
proxy_temp_file_write_size 64k;
}
# Static files location
location /media/ {
root /var/www/mysite/;
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: No "normalize" in locale(?)
Sorry about the thread hijack there, I mistakenly thought the problems were related. I'm using Python 2.5 on Ubuntu Hardy. It seems to me that the issue is the project locale directory is in my project folder. The fact that the locale folder for my project is called "locale" is causing a name space collision in the line: from locale import normalize I suffer from that newbie problem of not knowing what the best / standard default configurations are. The locale directory was placed in the project root by ./manage.py makemessages -a So I was kinda loathe to move it out of there. Thanks so much for taking the time to look at the issue, I apologize if this is a simple problem with a simple solution... On Aug 24, 1:29 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2008-08-24 at 10:14 -0700,PrairieDoggwrote: > > I ran into this problem as well when I upgraded to the most recent > > django trunk. I found out about it because my tests failed the > > following error: > > > from locale import normalize > > ImportError: cannot import name normalize > > So you've kind of hijacked the original thread here, since this is a > separate issue (I've changed the topic for that reason). > > What version of Python are you using on which OS/platform? The > locale.normalize method is certainly in Python 2.3 by default (and later > versions). Are you running some kind of cut-down Python install? > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: locale name conflict (deploy issue)
I ran into this problem as well when I upgraded to the most recent django trunk. I found out about it because my tests failed the following error: from locale import normalize ImportError: cannot import name normalize Whoever is writing the patch for ticket #5494 (http:// code.djangoproject.com/ticket/5494) _may_ want to take this into consideration. On Aug 16, 7:47 am, dcoy <[EMAIL PROTECTED]> wrote: > I figured this problem should occur in my windows environment as well. > So I did some tests but I never got that import problem. > In sys.path on windows the current dir is first (same on linux) so > python should start to look in the current dir for "locale". But > somehow the problem only arises on linux (which is running python 2.4, > windows is running 2.5, could that be it??) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Performance Discoveries Part 1
I'm still trying to wrap my head around what the advantages of worker MPM are, I've read a couple articles that have started me down this road - the consensus view seems to be worker MPM w/ mod_wsgi is the best way to go from a memory and separtion of concerns POV, the only potential drawback being that your django app needs to be 'thread safe'. Sadly I'm too much of a novice to really understand what that means in terms of my code or what sorts of patterns I should be using or avoiding. On Apr 27, 7:17 am, rich <[EMAIL PROTECTED]> wrote: > Thanks for sharing! > > My setup is similar to yours except I don't use nginx at all - just > another apache virtual host for media.mysite.com. Not sure which is > best, but one less moving part from my point of view? > > I haven't done any load testing, but I really like the way mod_wsgi > works; I use it in daemon mode (with worker MPM Apache) - it's never > caused me a problem and **feels** tidier than fcgi. > > Also I have much less memcached - only 16MB, but I'm on a 256Mb > slicehost slice, for now; I haven't explored any optimisations here as > I'm still building core features in my first django project. > > I've had one drama where Gutsy crashed: out of memory, unfortunately I > didn't realise until all log evidence fell off the end of the syslog > cliff. > > Happy optimising > Rich > > On Apr 27, 3:16 pm, Prairie Dogg <[EMAIL PROTECTED]> wrote: > > > Hey Everybody, > > > I've been using django for almost a year now and I've been spending > > some time recently trying to optimize the slicehost VPS(s) that I use > > to run several django sites I've developed. I wanted to share my > > findings with the larger group in hopes that my oversights can be > > pointed out and whatever 'findings' I've made can be useful to folks > > who are just starting off. I've been developing a blow-by-blow of my > > slicehost setup - I gained a lot from the "dreamier django dream > > server" blog post a while back. But to make things brief for the > > first post, I'll just summarize my setup here: > > > 512 meg slicehost slice w/ Hardy Heron > > memcached with cmemcached bindings doin' its cache thang with 256 megs > > of RAM > > nginx on port 80 serving static files > > apache mpm worker on 8080 w / mod_wsgi serving dynamic content > > postgres 8.3 w/ geo libraries > > django_gis (thanks justin!) > > my application > > > I'll keep it to 3 sections of musings for this post: > > > triage troubles > > memcached musings > > context-processor conundrum > > > triage troubles > > > At pycon someone asked Jacob KM what he used to performance test his > > websites and he said "siege". A quick google search turned it up > > (http://www.joedog.org/JoeDog/Siege). > > I seem to recall Jacob mentioning that this was his preferred method > > because it was more of a "real life" test than perhaps benchmarking > > tools that would profile the code. Compiling and using siege was a > > snap. My test was of a site I wrote that does a lot of database > > queries to draw up any given page (mostly because of a complex > > sidebar) when I turned it on, real easy like, to a dev server, the > > server crumbled with only 10 simultaneous users and anything higher > > than 5 clicks per user. > > > Observation #1: Make sure your debug settings are turned off. > > > After I turned debug settings off, performance maybe doubled, but > > still was nothing that could handle even moderate traffic gracefully. > > 20 simultaneous users on 3 clicks per user were getting up into the > > 20+ second wait for a response range. Basically awful. Not shocked, > > because I knew that my db querying was horrendously inefficient. This > > was OK, because I had memcached up my sleeve. An observation that I > > made on the first test that was constant throughout all subsequent > > tests, was that initial queries were the fastest and subsequent > > queries became progressively slower and slower. I'm assuming this is > > because of something like queries queuing up at that db, or running > > through memory, but I don't have enough context or knowledge of the > > whole stack to isolate the problem, more on this later. > > > memcached musings > > > I went on and compiled cmemcache because the consensus opnion on the > > internets is that its fastest. I'll just assume that's so because it > > has 'c' in the name and if you read it on the
Django Performance Discoveries Part 1
Hey Everybody, I've been using django for almost a year now and I've been spending some time recently trying to optimize the slicehost VPS(s) that I use to run several django sites I've developed. I wanted to share my findings with the larger group in hopes that my oversights can be pointed out and whatever 'findings' I've made can be useful to folks who are just starting off. I've been developing a blow-by-blow of my slicehost setup - I gained a lot from the "dreamier django dream server" blog post a while back. But to make things brief for the first post, I'll just summarize my setup here: 512 meg slicehost slice w/ Hardy Heron memcached with cmemcached bindings doin' its cache thang with 256 megs of RAM nginx on port 80 serving static files apache mpm worker on 8080 w / mod_wsgi serving dynamic content postgres 8.3 w/ geo libraries django_gis (thanks justin!) my application I'll keep it to 3 sections of musings for this post: triage troubles memcached musings context-processor conundrum triage troubles At pycon someone asked Jacob KM what he used to performance test his websites and he said "siege". A quick google search turned it up (http://www.joedog.org/JoeDog/Siege). I seem to recall Jacob mentioning that this was his preferred method because it was more of a "real life" test than perhaps benchmarking tools that would profile the code. Compiling and using siege was a snap. My test was of a site I wrote that does a lot of database queries to draw up any given page (mostly because of a complex sidebar) when I turned it on, real easy like, to a dev server, the server crumbled with only 10 simultaneous users and anything higher than 5 clicks per user. Observation #1: Make sure your debug settings are turned off. After I turned debug settings off, performance maybe doubled, but still was nothing that could handle even moderate traffic gracefully. 20 simultaneous users on 3 clicks per user were getting up into the 20+ second wait for a response range. Basically awful. Not shocked, because I knew that my db querying was horrendously inefficient. This was OK, because I had memcached up my sleeve. An observation that I made on the first test that was constant throughout all subsequent tests, was that initial queries were the fastest and subsequent queries became progressively slower and slower. I'm assuming this is because of something like queries queuing up at that db, or running through memory, but I don't have enough context or knowledge of the whole stack to isolate the problem, more on this later. memcached musings I went on and compiled cmemcache because the consensus opnion on the internets is that its fastest. I'll just assume that's so because it has 'c' in the name and if you read it on the internets, it must be true. I put in all the cache settings, put in the Cache middleware and ran siege again, waiting for the glorius results. Blam. Exactly the same. Actually, a little worse. I scratched my head for about 3 hours before I realized that I had mistyped the memcached port number in the settings. After that, much improved. I could do 300 simultaneous visitors doing 3-5 clicks apiece with tolerable performace. 1000 visits doing 1 click each also held up very well, the longest response time being in the 4-6 second range. Without fail, the earliest requests were the shortest wait, many well under a second, the last requests were the longest waits. Also, as I ratcheted up pressure from siege, I was running top on the 'beseiged' server watching the running processes. I notice a ton of postgres processes. This challenged my notion of how memcached worked. I thought that memcached would take the resulting page for a given view and spit it back out if the url was requested again with no database involved. I was still hitting the db _alot_. Observation #2 Is this thing on?: Memcached really does dramatically improve your sites responsiveness under load, if you don't see massive improvement, you haven't gotten memcached configured correctly. context-processor conundrum Then I remembered that I had written a custom context processor that was doing the bulk of the nasty database querying. I reckon that whatever the order of operations was for request / response handling, the result of the context processing was not getting cached. So I wrote 4-5 lines to check / set the cache in my custom context_processors.py and voila, that instantly knocked all queries to the db down to zero. Despite the absense of postgres processes stacking up, the same phenom of early queries fast, subsequent queries slow still applied, at this point I'm not exactly sure what's causing it. It's not that it's surprising, its just that I'd like to understand exactly why its happening. Observation #3: Low level cachin' works well in cases like context_processors, or other expensive non-view functions. OK - I'll stop here for now, I hope this was useful or at least amusing. I'd love to hear s
Re: Queryset-refactor branch has been merged into trunk
Malcolm: Sorry - it's late over here, didn't mean to mis-type your name. File this and previous under: damn-life's-work-with-faint-praise On Apr 26, 11:29 pm, Prairie Dogg <[EMAIL PROTECTED]> wrote: > Malcom, > > Thanks so much for your tremendous effort and success on this! > > You rock! > > On Apr 26, 11:04 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > I merged queryset-refactor into trunk just now. This was changeset > > r7477. > > > There are still a couple of enhancements to do, but I've decided they're > > not worth holding up the entire branch for. I can just as easily do them > > on trunk. > > > Thanks to everybody who reported bugs and tested things. Thanks > > especially to Justin Bronn and Ian Kelly for lots of patches and testing > > to get the Oracle backend up to scratch on the branch. > > > Detailed list of changes is in the branch's wiki page ([1]) and if > > you're interested in seeing the documentation additions and changes, you > > can view [2]. > > > [1]http://code.djangoproject.com/wiki/QuerysetRefactorBranch > > [2]http://code.djangoproject.com/changeset?new=django%2Ftrunk%2Fdocs% > > 407477&old=django%2Ftrunk%2Fdocs%407411 > > > No more bugs should now be reported against the queryset-refactor > > version. The branch is closed. > > > Regards, > > Malcolm > > > -- > > On the other hand, you have different > > fingers.http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Queryset-refactor branch has been merged into trunk
Malcom, Thanks so much for your tremendous effort and success on this! You rock! On Apr 26, 11:04 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I merged queryset-refactor into trunk just now. This was changeset > r7477. > > There are still a couple of enhancements to do, but I've decided they're > not worth holding up the entire branch for. I can just as easily do them > on trunk. > > Thanks to everybody who reported bugs and tested things. Thanks > especially to Justin Bronn and Ian Kelly for lots of patches and testing > to get the Oracle backend up to scratch on the branch. > > Detailed list of changes is in the branch's wiki page ([1]) and if > you're interested in seeing the documentation additions and changes, you > can view [2]. > > [1]http://code.djangoproject.com/wiki/QuerysetRefactorBranch > [2]http://code.djangoproject.com/changeset?new=django%2Ftrunk%2Fdocs% > 407477&old=django%2Ftrunk%2Fdocs%407411 > > No more bugs should now be reported against the queryset-refactor > version. The branch is closed. > > Regards, > Malcolm > > -- > On the other hand, you have different > fingers.http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Fixture? Testing? how do you do it?
I just did this for the first time last night, although I definitely don't know how to write good tests, at least I wrote some tests. First thing you'll wanna check out if you haven't is: http://www.djangoproject.com/documentation/testing/ But I assume you have, so I'll just get on to the fixtures. Probably the easiest way to create a fixture is to enter some data into your site from the admin interface. Then go to your project folder (the one with manage.py in it) and type something like: $>python manage.py dumpdata --indent=4 --format=json > my_text_fixture.json Both the --indent and --format flags are optional, I think the output is JSON by default. For more information on dumping data into a fixture, check out: http://www.djangoproject.com/documentation/django-admin/#dumpdata-appname-appname Then, when you write your unit tests for your app in tests.py, you simply load up that fixture at the beginning of each test case. The docs say that the test database is flushed and restored for each individual test case. Here's what one of my test cases looks like: class FormatTestCase(TestCase): fixtures = ['book/test_data/book_test_data.json'] def setUp(self): self.haiku = Submission.objects.get(title="A Peaceful Haiku") def testPermalink(self): self.assertEquals(self.haiku.get_absolute_url(), "/submission/ peaceful-haiku/") Hope that helps. Obviously, this only works for unit tests. I'm not entirely sure how you load fixtures for doctests, maybe someone more experienced would like to tackle that. On Apr 1, 12:31 pm, Tony <[EMAIL PROTECTED]> wrote: > I am relatively new to Django, and I am having trouble getting my head > around fixtures. > The Django documentation just assumes that you should know what a > test fixture is and how to write one. I understand that fixtures are > just test data, but how is one written? > > Any guidance/examples on this would be great. > > Thanks, > Tony --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: The best practice for a registration and then getting user to fill up extra information
Just thought I'd add that I went through the exact same thing, spent a couple hours integrating django-registration only to find django- profiles later, gotta say that the little google maps locator in django-profiles is really nifty. I've had to make some modifications to django-profiles to correct what I'd consider deviations from "best- practices", but that may very well be my own bias. Specifically, I added email address collection at registration, auto-login on registration, etc. On Feb 10, 10:10 am, "Ramdas S" <[EMAIL PROTECTED]> wrote: > James, > > Thanks! I need to learn to ** search better ** :) > > RS > > > > > On Feb 10, 2008 8:18 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > > > On Feb 9, 2008 9:37 AM, Ramdas S <[EMAIL PROTECTED]> wrote: > > > > I am using Django-registration. It works like a charm as far as > > > registering > > > > new users and validating them from potential bots. However, what is > > > the best > > > > practice as far as getting users to feed in more information. > > > > See django-registration's lesser-known companion application: > > > >http://code.google.com/p/django-profiles/ > > > > -- > > > "Bureaucrat Conrad, you are technically correct -- the best kind of > > > correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Web Development with Django: Windows vs Linux/Mac OS X
I'm doing the vmware situation for my local machine (Mac OS X). I built a vmware image for my dev environment to mirror my production environment (apache / mod_python backend with nginx serving the static content). The only difference between the two machines is that the dev machine is running netatalk so that I can edit the files on the dev server directly with the whole suite of mac apps. Because both the production and dev environments are linux, there are a bunch of tools that make administration easier like ssh for access, rsync for backup, and if you keep the data on the dev server and production server synced, you can always have a hot copy running in case you do something disastrous in the production environment. That being said I'm still looking for the perfect IDE to cap this off. Komodo IDE for OS X is the only one so far whose SVN support is intuitive and I love their live folders (which works perfectly with the netatalk setup). I've used eclipse, however, and have to say that I like their customizable interface better than Komodo's. The price of Komodo vs. Eclipse might also make the difference here $295 vs. Free. I'd love to hear any setup details of folks who run local vmware dev servers on macs with an Eclipse (or other) IDE as I'm currently shopping around. Good luck w/ your setup! On Feb 7, 11:40 am, Doug B <[EMAIL PROTECTED]> wrote: > Another alternative is a virtual server via vmware running a small > barebones/server install of your favorite distro. There are a number > of pre-built vmware images online, and vmware player is free now. It > worked out really well for me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
simple django notifications app questions
I'm writing a very simple django app for use on a learning project that I would love to get some informed commentary on. The app basically helps users mark content objects that they would like to watch, and sends out email updates to users whenever objects related to the "watched objects" have been added. Simple use cases include "watching" a blog post for comments - or in the learning site I'm building, "watching" a situation for metaphors that users have added. I'm new to designing web applications and to django so if anyone was feeling curious and helpful, feel free to take a look at the learning project: metaphorme.com and at a wiki page I put up with code snippets describing my design process and particulars in more detail. There are some questions at the end of the wiki, but feel free to edit away anywhere! The wiki address is: http://asktheinternets.com/wiki/Django_notifications Also, I'd like to mention that I do know about the approach on: http://superjared.com/entry/comment-notification-django/ but somehow editing the __init__.py file didn't seem like a clean way to do things. An ultimate goal for me is to make this notifications app portable and extensible ... looking forward to your thoughts and comments! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
