Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eighteen months of Django

dangoldin.com

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Eighteen months of Django

#71

Post by ludwigvan »

crdoconnor wrote: post #37
obviouslygreen wrote: post #24

Earlier quoted context omitted.

Note that periodic execution, one of the more useful aspects of celery, is not supported on all backends. If you're using rabbitMQ, you're golden. If you're using most or all other transports (including SQS), you're likely SOL and will have to resort to either bare cron jobs or something like django-cronograph that accomplishes the same thing. celery is definitely nice, but it does have its limitations (like everythi…

This is good to know. I've just started using it with redis. I never really saw the point of that part of celery anyway. Cron's perfectly adequate on its own (and installed just about everywhere).

I'm using cron instead of celery daemon for those tasks, but here are two advantages:

- being able to modify the task frequency from the admin

- cron needs special care with setting the environment variables like PATH

Re: Eighteen months of Django

#72

Post by camus »

ceol wrote: post #46
crdoconnor wrote: post #38

Earlier quoted context omitted.

Returning to PHP land afterwards feels like you're taping your code together with duct tape and bits of string.

At the risk of this becoming a "bash PHP" thread, that's exactly how I feel. Unless I'm doing something very simple, it's always easier, cleaner, and simpler to do it in Python. Even building a basic CRUD app is night and day between the two languages; Django is beautiful and intuitive, while the PHP frameworks come close but have a few snags that make working with them frustrating. I write this not to meaninglessly…

The fact is PHP has excellent frameworks. I tried Django and Flask , and love them. But for now , i'm sticking to PHP( to much legacy code to port ). For new projects ? sure. The only thing which is a bit more complicated with serverside python is deployment on client servers, the rest ( development , testing ), is easier than PHP. I only wished Python had type hinting for functions and methods like PHP does though. Aside from these issues , Python is perfect,more consice and have awesome stuffs like decorators. And a whole lot of awesome libraries.

Re: Eighteen months of Django

#73

Post by ludwigvan »

Here are a few other Django packages that I haven't seen mentioned in this thread:

- Gargoyle: Feature switches in Django https://github.com/disqus/gargoyle

- webassets and django-assets: For minifying static assets

- raven + sentry for logging. Sentry is the server, so actually can be used with any project, not only Django.

- django_extensions: Provides some helper management commands, for example manage.py shell_plus which automatically imports your models

- dbbackup for backing up your db to S3 or Dropbox

Re: Eighteen months of Django

#74

Post by lmm »

ceol wrote: post #46
crdoconnor wrote: post #38

Earlier quoted context omitted.

Returning to PHP land afterwards feels like you're taping your code together with duct tape and bits of string.

At the risk of this becoming a "bash PHP" thread, that's exactly how I feel. Unless I'm doing something very simple, it's always easier, cleaner, and simpler to do it in Python. Even building a basic CRUD app is night and day between the two languages; Django is beautiful and intuitive, while the PHP frameworks come close but have a few snags that make working with them frustrating. I write this not to meaninglessly…

I'm getting the same feeling now that I have to work in python/django after having used scala. So it's always worth trying new languages, even when you've found one that seems great at the time.

Re: Eighteen months of Django

#76

Post by iends »

jordn wrote: post #70

For those who would like to get started with Django, here's a skeleton project https://github.com/jordn/heroku-django-s3 and guide helps get you set up quickly with: - hosting on heroku - static files on Amazon S3 - virtualenv(wrapper) isolated packages - environment and security critical variables removed from settings.py and stored as environment variables (following the 12-factor design ethic)

I have a couple of thoughts:

1. Why not use django-admin.py startproject --template=? I typically do something like django-admin.py startproject --template=https://github.com/rdegges/django-skel/zipball/master mynewproject so I don't actually have to clone

2. No runtime.txt for heroku?

3. Not specifying version numbers in your requirements.txt is very dangerous. I prefer something like "Django>=1.5.0,<=1.5.9"

Re: Eighteen months of Django

#77

Post by aidos »

lucian1900 wrote: post #64
aidos wrote: post #15

Earlier quoted context omitted.

Neither! Actually, as the others have said it completely depends on what you're making. Django is great if you're making a standard cms type website. News feed, blog, etc. There's a bit of a learning curve but it gives you a lot of the scaffolding out of the box (and there are loads of examples to learn from). It has the biggest community (I guess?) so you'll always be able to find answers / libraries / sample code.…

To be fair to Flask, there are lots of libraries you can add to it (Flask-Script, Flask-WTF, Flask-Auth, Flask-Admin) that replicate pretty much all of the functionality of Django, but in a more modular fashion. For example, I can use Flask-Auth regardless of if I've chosen Flask-SQLAlchemy.

Indeed - I just didn't want to push Flask too much but that's what I use and I bring in the libraries you mention as and when they're required.

Re: Eighteen months of Django

#78

Post by dangoldin »

tomkinstinch wrote: post #20

I'll add that if you need to background anything, django-celery makes it easy. celeryd is also good for scheduling tasks with either single or periodic execution. http://docs.celeryproject.org/en/latest/getting-started/firs... You can also use it in a typical task queue role. It will pickle or serialize the Python objects that accompany tasks for transmission over the wire.

Yea - that's going to be one of the packages I mention in the follow up. I ended up using RabbitMQ as the backend for it which wasn't that easy to setup so I am curious to see what others are using.

Re: Eighteen months of Django

#79

Post by dangoldin »

stevenwei wrote: post #25
adamrt wrote: post #12

Using S3 for static media makes perfect sense, but does anyone have information on S3 when your contributors (users in the admin) are uploading lots of images for via something like django-filebrowser or a simple zipfile upload (that extracts the images into a folder)? I haven't seen anything like this in any examples.

I think the standard method of dealing with this is to have your users upload the items to the local web server and then have some sort of async task or cron job responsible for moving the files to S3 later on. Of course this means you'll have to keep track of where the uploaded file is currently located, but if you ever want to scale to multiple web servers you'll need to do that anyway.

Yea - this is how I've been doing it. The server that gets the upload does some processing and then moves the content over to S3 and adds an entry to the database that references it. It also forces you to write stateless code which is nice bonus.

Re: Eighteen months of Django

#80

Post by dangoldin »

chrisdl wrote: post #39
tacticus wrote: post #31

Earlier quoted context omitted.

So a stupid question about virtualenv for you. Why does it default to full paths for everything?

I actually don't "know" either. But I suspect it has to do with knowing which python to use (system generally) and if the user wants to use global packages as well. checkout virtualenvwrapper ( http://virtualenvwrapper.readthedocs.org/en/latest/install.h... ) as well for handling virtualenvs.

Author here - thanks for mentioning this! I've never used it but will give it a go.
Post reply on HN