
Things I Wish I Had Known About Django Development Before Starting My Company - misiti3780
https://medium.com/cs-math/f29f6080c131
======
streblo
12\. Use `pip freeze` to keep a list of your requirements, and keep that
requirements list in your repo. Use virtualenv and virtualenvwrapper to keep
your environment clean from other environments. Virtualenvburrito
(<https://github.com/brainsik/virtualenv-burrito>) will help you set it all
up.

13\. You almost never need to write bash scripts. Use django management
commands to write scripts that interact with your application. Use fabric and
a fabfile to do deploys. Use something like chef or puppet to do machine
configuration. Your bin/ folder will turn into an unmaintainable mess very
quickly.

14\. Use south. Yes, it's obtuse, but it gets the job done.

15\. Use a pre_save hook on all of your models to do full_clean for validation
before anything goes to the database. This will save you from cleaning up your
data later.

    
    
        from django.db.models.signals import pre_save
    
        def validate_model(sender, **kwargs):
            if 'raw' in kwargs and not kwargs['raw']:
                kwargs['instance'].full_clean()
    
        pre_save.connect(validate_model, dispatch_uid='validate_models')
    

16\. If you're writing a javascript-heavy application, consider all of your
options for static asset management before you get too deep. I've used django-
compressor, django-pipeline, webassets, and django-gears. None of them are
perfect solutions (there still isn't a sprockets-esque one-catch-all solution
for django like in the rails world), so consider the pros and cons before you
make a choice.

edited for formatting

~~~
elithrar
> (there still isn't a sprockets-esque one-catch-all solution for django like
> in the rails world)

This is definitely a little frustrating. I'd kill for a solution that handles
minification, versioning & can upload to S3/etc. You can pass things through
boto to get to s3, but the rest requires a bit of fiddling.

I've seen a few solutions that come close, but then they have extremely odd
versioning systems. I should just fork something so I can add an ISO8601
timestamp to my CSS & JS; which I like because having granular dates helps
when debugging front-end issues.

~~~
kevinastone
What have you tried? Because staticfiles + django-storages + django-compressor
sounds like it can handle that use case.

~~~
th
I'm using exactly that setup and it does work, it just took me many hours and
over 100 lines of custom storages + settings code to get it working.

I had to solve issues with custom domains, HTTPS, gzip, separate media/static
files buckets, and storages/compressor not playing nicely together in general.

~~~
ritchiea
I have been developing with rails for a couple years, though I am comfortable
with python I've never touched django because I haven't had to and one thing I
will say is that the rails asset pipeline documentation is something I
constantly return to. The asset pipeline provides a lot of functionality but
not a lot of simplicity or management of complexity. If what you wish you had
from rails is the asset pipeline you are either either an expert with with
rails api or you are seeing things greener on the other side of the fence.

I don't mean to insult the asset pipeline, it provides a lot. But it
definitely doesn't save you hours. Out of the box the asset pipeline is great
for all the things that come for free but if you are doing a lot of
development in the framework you probably return to the asset pipeline
documentation on a regular basis. And I consider time spent in documentation a
negative compared to time finding your own solution if the API is not
intuitive and you find yourself consistently returning to the docs about
similar problems. And let me tell you, plenty of my fellow Rails devs have
said to me they also regularly return to the asset pipeline docs.

------
pindi
> Django does not have a built in JSON HTTP response, so you are going to have
> to either man up and roll your own (good luck)

Am I missing something? What's wrong with:

    
    
       return HttpResponse(json.dumps(data), mimetype='application/json')
    

Wrap it up in a convenience function and you're done.

The JSONResponse class suggested automatically implements JSONP, which is
extremely dangerous. Consider a view on /accounts/info which returns some
information about the currently logged in user. A malicious site could embed

    
    
      <script src="http://example.com/accounts/info?callback=someFunction">
    

and access the account information of any user logged into your site. JSONP is
a technique to _bypass_ the same-origin policy in appropriate cases; don't
just blindly apply it everywhere or you're giving up the protection of the
policy.

~~~
peterhunt
json.dumps() can be dangerous if used on your raw domain data. You should
specify the exact schema being sent down to the client so you don't
accidentally leak something (this can happen very easily in Python)

~~~
jaegerpicker
yep, I build response objects ( my own term, not great but it describes what
they are ) that are basic subsets of the object that I want to serialize to
json. That way I'm sure only the fields that I really want to send are making
it out.

~~~
peterhunt
Cool, I think a good JSONResponse implementation would bake that into the
framework such that it's difficult to make the mistake you didn't make :)

------
apendleton
> Use Gunicorn instead of Apache for your webserver

This is strange advice; while you _can_ use gunicorn as a front-facing
webserver, the gunicorn docs strongly recommend against doing so. In a typical
deployment scenario, then, gunicorn and Apache would occupy different levels
of your stack, with one running your WSGI app and the other exposing it to the
world. The advice ought probably to be "Use gunicorn+nginx instead of
Apache+mod_wsgi," and indeed, lots of people do make that recommendation about
Django deployment.

~~~
misiti3780
sorry - i did forget to mention nginx should be in front of everything
managing all requests + serving static content.

~~~
misiti3780
updated article

------
falsedan
1\. package your python code as a sdist (except setuptools is too hairy so
nevermind), keep your deployment scripts & configs in a separate repo or
orphan branch

3\. use nginx to reverse-proxy WSGI to Gunicorn over a unix socket

6\. don't have per-environment config in your app, use the same config in all
environments and configure each host with aliases/proxies to consume the
appropriate resources (use local_settings.py for local development on your
workstation & exclude it from your package)

7\. use native operating system service management (systemd, upstart, launchd)

10\. use munin if your app can withstand a CPU spike every 5 minutes, use
ganglia/graphite/collectd otherwise

~~~
hcarvalhoalves
> 1\. package your python code as a sdist (except setuptools is too hairy so
> nevermind), keep your deployment scripts & configs in a separate repo or
> orphan branch

This. I'm tired of Django projects not being packaged/released correctly, and
deploy scripts that simply git clone in production (yiikes).

~~~
subleq
Could you go into some more detail about what being 'packaged correctly'
means? What's wrong with a git clone deployment, why is deploying as a package
better, and how does one implement it correctly?

~~~
hcarvalhoalves
I love how I got downvoted for mentioning git clone deploys.

> What's wrong with a git clone deployment, why is deploying as a package
> better, (...)

The advantage is that you can have a _release_ process, where you update the
package's __version__, compile/minify the files you need, build documentation,
and so on, until you have a deployable branch that you can tag and upload to
the repository. This way you have a reproducible history of releases, it's
easier to inspect which version is deployed, you have hooks for installation
(for instance, you can abort installation if the tests fail on production),
etc. Mainly this:

Crank out code -> Run a makefile/fabfile to update
version/compile/minify/build whatever -> Export a tag -> Build an sdist/bdist
-> Install on production

I believe too many things grew inside Django (e.g. collectstatic) that really
shouldn't be part of the framework at all. Another thing that bothers me is
South: you need to push a release to production, _then_ run a migration,
because the migration is part of the codebase. Well, the migration really
should be part of the installation process. There are corner cases where this
is an issue - for instance, worker processes reloading _before_ your migration
is complete would use the new, wrong model definitions, and suddenly you have
a broken release on production.

For all effects, your Django project should just be a valid Python package
that you can pip install in a virtualenv inside your server (lets say,
/opt/<myproject>) and you're done with it. This way you can freeze the
environment on production, pip can handle upgrade/downgrade, you don't have to
care about *.pyc hell, etc.

> and how does one implement it correctly?

I should probably upload a project template with a workable setup.py to
github.

------
famousactress
Solid list! For most of those bullets I definitely had the 'Oh wow, should
have done this sooner' moments. I'd add:

\- use South (right away!)

\- Class Based Views

\- (not django specific) use virtualenvs!

~~~
mrtron
Am I the only one left who finds south more trouble than it is worth?

~~~
pico303
I came to Django & South after using ActiveRecord and Rails migrations for
years, and it drove me nuts. Not trying to cause a big argument, but why the
big push in the Python community to model database tables via object
properties/fields? I seem to recall SqlAlchemy does something similar.

~~~
regularfry
DataMapper 1 does the same. It does make sense if you're worried about changes
to your database schema spontaneously breaking previously working code.

~~~
pico303
No, I get that part. I'm talking more about building a database from models.
It seems like these tools are designed to build the database scheme from the
object models, which to me is just as bad as building the objects from the
schema.

Ideally, we should use the declarative style of Django models and SqlAlchemy
on the object, along with the scheme generation tools of Rails migrations.

------
dhaivatpandya
I wish there was something like this for rails - well written, concise and
keeps the newbies away from things that'll hurt them. In particular, some
major pain points:

1\. Use rbenv or rvm. Half the problems I notice with beginners stem from
installing rails with apt-get or something.

2\. Your controller is meant to be simple glue between model and view - if
you're putting tons of code in there, you're doing it wrong.

3\. Unit test. A lot. This is especially good for beginners because you often
make little errors when you're starting out.

4\. Unit testing isn't enough. Functional testing is important too.

5\. Learn about your hosting provider. Specific to Heroku, if you're on the
free plan, every dyno spin-up takes absolutely forever if you don't have a
steady stream of visitors.

~~~
Iterated
I started reading about Django recently so this is a noob question, but what's
the controller in Django? All I've seen with with a lot of code is models,
views, and templates. It's kind of annoying how tutorials talk about MVC but
it doesn't seem like an MVC framework.

Also, if I want a user to input numbers to do calculations, where does the
computationally heavy code go?

~~~
davesque
For most intents and purpose, "controllers" from so called MVC frameworks are
referred to as "views" in Django.

The article that edavis mentions does make one good point, which is that the
term "view" was chosen to emphasize the notion that the python callback
function (or object) sets up a view of the data represented by the models. I
think there's something good in this choice of words. I find the terms "view"
and "template" more intuitively meaningful than the corresponding "controller"
and "view".

One important, substantive difference that I'm aware of between controllers in
many MVC frameworks (probably not all) and views in Django is that a lot of
MVC frameworks map requests to controller actions through URL traversal,
whereas Django offers a more hands-on approach with URL confs.

Also, whereas controllers are often implemented through classes in MVC
frameworks, views in Django may be implemented through any callable object
which accepts a request and returns a response.

As far as where your code should go, it probably depends on what kind of data
the user is entering. If the data must be persisted in the database somehow,
such as with transactions in a bank account, then the code that crunches the
numbers would probably be in a method on a "BankAccount" or "Transaction"
model class. If it's data that only really needs to persist for the user's
individual browsing session, then it's probably safe to put the code that
works on it in a view. Django limits what kinds of things you can do in its
templates (thankfully), so you probably won't have much luck putting your
computation code in a template.

------
bryanh
Watch out for these Celery gotchas:

1\. Tracking tasks status in SQL will result in a _lot_ of queries! (Even when
using Redis/RabbitMQ as brokers.)

2\. Crontab style tasks are great... until they take a long time to complete
and Celery kills them. And then you're back to regular crons (and there is
nothing wrong with that).

3\. Use UTC everywhere! New projects get this by default, but don't make this
mistake.

~~~
jdunck
My recc after a lot of heavy use is: RabbitMQ for the queue, Redis for the
result store.

RabbitMQ for the result store is madness.

~~~
misiti3780
why not just use redis for both - just curious ?

~~~
jdunck
Redis does OK as a queue, but not as well as rabbit.

For a start, rabbit handles OOM better. It has lower per-message overhead. It
has a more flexible queueing model in general so that you can use it for both
work queue-y stuff and other queuing needs. It's interesting how often queues
seem handy once they are easy to use.

Then there's the fact that redis is good for lots of things other than queues,
and you'll be tempted to use it for that, and that will crowd the queue use.
If you hold a transaction on redis or do a large set intersection or run a lua
script, you block everything else, including your fanned-out celery worker
pool.

------
deepakprakash
This is indeed a solid list.

The most comprehensive best-practices resource of Django I've come across by
far is "Two Scoops of Django"[1] by "pydanny"[2]. Its absolutely worth the
$17.

[1]: <https://django.2scoops.org/> [2]: <http://pydanny.com/>

~~~
pydanny
Correction: It's not by "pydanny", it's by "pydanny" and "audreyr". She just
doesn't do the whole Twitter/HN/blog thing as much as me. Seriously, do you
think I could write a section including code that discusses "the impossible
condition of too much chocolate". ;-)

Seriously, between the two of us she's the better coder, taught me LaTeX, and
knows Strunk and White. I just write what I think and let the grammar experts
fix it. :P

------
dangoldin
An item I'd like to add to Python development in general is to use virtualenv.
If you're doing multiple Django projects this is a must have.

One of those tools that you start off thinking isn't useful but quickly turns
into a must have.

------
kitanata
I'm not sure why this article suggests that you should use jammit when a very
nice django specific implementation does the same thing. If you are using
django do yourself a favor and skip jammit in favor of django-compressor here:
<https://github.com/jezdez/django_compressor>

If you want haml templates in 1.3 or 1.4 use my fork of djaml here:
<https://github.com/kitanata/django_haml>

For all the other asset specific stuff use node packages like less and
coffeescript. There is no need to include any rails or ruby code in with your
django projects. Good alternatives exist.

------
nnq
> Use Gunicorn instead of Apache for your webserver [...] This assumes NGINX
> is managing all incoming requests and serving static content.

Why not just go nginx + django the usgi way? Now you have friendly tutorials
and docs for this like
[https://uwsgi.readthedocs.org/en/latest/tutorials/Django_and...](https://uwsgi.readthedocs.org/en/latest/tutorials/Django_and_nginx.html)
. Maybe I'm weird or I've never worked on large enough apps, but I fail to get
what the shiny unicorn and gunicorn bring useful tot the table...

------
spamizbad
> 10gen has added the aggregation framework, full-text search, collection-
> level locking, etc.

Mongo has collection-level locking? I thought there was some preliminary work
to support it in 2.2 (It just does database-level locking for now), but it's
still unsupported. Source: <https://jira.mongodb.org/browse/SERVER-1240>

Also, I wouldn't recommend using any of the aggregation stuff unless its for
infrequent ad-hoc stuff or scheduled tasks during slow periods.

~~~
conesus
I use aggregation queries regularly and it's amazing. My MongoDB database has
4k ops/sec and I run an aggregation query to count averages, sums, and splits
on a name (to get averages and sums for each of two dozen groups) for about
10K rows every 5 minutes. Not a huge amount, but this is on a db that is
performing a ton of work. Also, I should mention that you should probably run
your aggregation queries on your secondaries.

~~~
misiti3780
i agree - the aggregation framework seems solid - much better performance than
map-reduce

------
falcolas
I don't see a monitoring system there? Something like Supervisor is great, but
who watches the watcher? I prefer Nagios, but that's just because I'm used to
it. Even it is better than nothing.

If you want something a bit more distributed (read less prone to single points
of failure) than Supervisor, check out pacemaker. Very powerful and useful for
keeping resources alive in any sized cluster.

------
coolsunglasses
Don't use celery use: <https://github.com/binarydud/pyres>

~~~
mcintyre1994
I've been expecting to use Celery in a project I'm working on, could you
explain why?

~~~
coolsunglasses
Celery is a PITA and over-complicated for the problem it solves.

~~~
rozap
Do you know why pyres relies on itty? Seems like kind of an odd dependency...

~~~
lost-theory
The pyres web interface (where you can view job status) is built using itty.

edit: looks like they're using flask now, I don't see itty being used
anywhere. They also split the web interface (resweb) into a separate project,
so pyres doesn't depend on a web framework now.

~~~
rozap
Ah ok, thanks. I guess the documentation is a little outdated then. Thanks for
the suggestion, I'll check pyres out when I get to that point in my project.

------
Judson
This may sound strange, but when I first started doing python stuff with
Django, I spent WAY too long trying to figure out the best project directory
layout. To me, Django should generate a "pretty-good" directory layout, much
like `rails new`.

------
scottrb
My supreme thanks to the author for writing this and to all those who have
submitted additional items to the list in the comments here. I'm writing my
first few Django apps in series and have found this bits of advice to be very
valuable.

------
dshap
I haven't used Jammit before, but I highly recommend checking out django-
pipeline for the same purpose: <https://github.com/cyberdelia/django-pipeline>

~~~
Bockit
Specifically for me, pipeline fits into django's collectstatic way of doing
things. And because of this it works fantastically with django-storages as
well. My projects are set up so that `python manage.py collectstatic` trawls
all my apps static folders, compiles everything if required (r.js, sass) and
uploads any changes to an S3 bucket. And in development it compiles over the
wire (except r.js, we let requirejs do the async loading thing in
development).

~~~
dshap
Ditto regarding everything up until your last sentence - it is a pretty great
setup.

What do you mean it "compiles over the wire" in development? In development,
pipeline just renders individual js/css tags for each of your static files,
un-compiled...

~~~
Bockit
That when we're developing, you edit a sass file, and when you request the CSS
file it compiles the SASS to CSS before serving the file. It has been a little
while since I set it all up but I think for the SASS example I've made a
gist[1] showing the settings you need to make it work. If I recall correctly
the key bit is using the .scss as the source file. Then, in production make
sure to set `PIPELINE = True` to stop compiling per request.

[1]: <https://gist.github.com/Bockit/5408958>

~~~
dshap
Gotcha

------
metaphorm
your django app doesn't look like a django app.

the basic premise of the django defaults is that app modules are pluggable and
self-contained. all of the static assets, templates, model code, view code,
migration files, management commands, etc. related to a particular app should
go in that app's folder (which is treated as a Python module with its own
__init__.py file). conventionally the app's folder is a first child descendant
of the top level project directory (i.e. its in the same directory as
manage.py)

~~~
taylorfausak
That's true about Django apps, but this post doesn't describe a Django app. It
describes a Django project.

------
Camillo
The main thing I wish I had known is that the ORM is rather limited (or, at
any rate, it was too limited for my app), and while you can use raw SQL, it
won't let you get model objects out of your own queries, which makes it
impossible to integrate with the rest of your app that uses the ORM [1]. The
first thing I'd do if I had to use Django again would be to eschew its ORM and
use SQLAlchemy instead.

[1] This was a few versions of Django ago; if they fixed this since then, I
welcome corrections.

~~~
edavis
Not sure when it was added, but is this what you were after?
[https://docs.djangoproject.com/en/1.5/topics/db/sql/#perform...](https://docs.djangoproject.com/en/1.5/topics/db/sql/#performing-
raw-queries)

~~~
Camillo
Yes, that looks like it should do the job. Thanks!

------
edanm
Thing #1 for me, by a long shot:

Deploy to Heroku (or similar). Saves a ton of headaches, saves boatloads of
time/money, and for most startups in the early stages, is well worth the
tradeoff.

------
SoftwareMaven
I decided to dive into bootstrap.py/buildout for my current project. So far,
it has done a reasonable job of keeping the directory structure clean as well
as keeping dependencies under control. The nice thing is that there are
recipes for most important things, and adding other new recipes (oh, I need to
install and have access to coffeescript) are very straightforward.

I see it as a build step before fabric or puppet would take the output and
deploy it.

~~~
crucialfelix
I've used buildout for years but I'm now moving away from it. I've enjoyed it
though, and I wouldn't recommend against it.

Several issues:

the buildout process is long and monolithic and not conducive to minor
adjustments. I'm using ansible now and its much better for just changing one
setting on an nginx config file or settings file and reloading. I chatted with
the author of buildout and he said he was building to an rpm and then mounting
that as his means to do a live deploy.

I often wished I had virtualenv, so many things work well with it. for
instance python-vim and sublime lint / rope like to have a virtualenv to get
the python paths. also ctags is happier if I can just enter the virtualenv and
run it.

there may be a recipe for that but I never found one that worked nicely.

------
tuxidomasx
This list is somewhat dependent on the size and complexity of the project. For
a small or simple project, many of these points might not matter.

For example, if Apache can handle your traffic just fine, why spend time
replacing it with gunicorn? Or if you never really migrate your database ever,
why waste time fiddling with South?

Just a gentle reminder to take into consideration the present and future needs
of your project to avoid needlessly adding complexity to it.

~~~
jvm
I think he's actually saying gunicorn was simpler than Apache. I've also found
that to be true (anecdotaly).

------
taude
I like the ideas on directory structure. I've been working in Flask and I
spent way too much time thinking about my directory structure.

~~~
Luyt
You're also using Flask? I wrote a short piece about roughly the same subject
as the author of the original article uses for Django. Running Flask behind
gunicorn and nginx, monitored by supervisord:

[http://www.michielovertoom.com/freebsd/flask-gunicorn-
nginx-...](http://www.michielovertoom.com/freebsd/flask-gunicorn-nginx-
supervisord/)

~~~
taude
Yes, using Flask. I need to write why we chose it over Django....but mostly
becasue we're using Mongo and once you're down the path of not using the
Django ORM, what's the point? Also, it seems like there's dozens of articles
on "how to structure" your large Django projects, so you don't even get good
guidance about it out of the box.

I'm running mine under NGINX->uWSGI....but might be switching to Gunicorn.
(I'm still researching our path to production).

------
overshard
I had to double check the title because I thought he said Django and all the
advice seemed to match my Rails experience and not my Django one, also, this
may be a bit nitpicky, but Django isn't really an MVC Framework nor is it a
CMS. You can only really call it a web framework as it has elements of these
items but isn't the same:

1\. The right directory structure, the default use for the media folder is
supposed to be using for stuff uploaded through your app, not the files you
develop, your static files should go in static and your compressed files
should go in media as they are dynamically generated or in your global
"static" folder that is pointed to from your web server. You should also have
different settings.py files on a per-situation basis. Your development
servers, staging, and production environments will probably all have different
settings because at the very least development will have `DEBUG = True` and
production `DEBUG = False`.

2\. This is fine even though it seems wonky to use it for cron jobs to me.

3\. This is fine too but I personally use nginx+uwsgi w/ emperor mode.

4\. Up to you on this one, there are some nice Django branches that support
key-value store databases but don't use the standard Django with key-value
databases because it is 100% built around RDBMS.

5\. Only piece of advice I agree with completely.

6\. As partially discussed in #1 by me. I don't like his override method. I
think an import of a base settings into production.py and development.py is
cleaner.

7\. Supervisor is good here but also if you use uwsgi in emperor mode instead
of the suggested gunicorn it can handle the same task saving you an extra
install and configuration.

8\. Django very clearly has a nice Mixin for JSON responses in the docs or you
can build a nice easy API using Tastypie:
[https://docs.djangoproject.com/en/1.5/topics/class-based-
vie...](https://docs.djangoproject.com/en/1.5/topics/class-based-
views/mixins/#more-than-just-html)

9\. It's up to you if you want to use Redis, I don't personally need it for
all the suggested things and I like how well memcached works with Django out
of the box for caching.

10\. Munin is great! I'm often too lazy to set it up and am fine reading log
files.

11\. This drove me to write this long comment... I actually get really annoyed
when people try to mix in items from other stacks when there are many solid
solutions already that don't force you to install another entire stack. Django
has django_compressor which works great in this situation
(<https://github.com/jezdez/django_compressor>) and a quick Google search will
find many other similar solutions that won't require you to install Ruby to
work with your Python web app.

Source: 6 years of developing Django apps and doing everything that was
suggested here and more.

~~~
akoumjian
How is Django not an MVC framework? I'm not being snarky, just curious.

~~~
steveklabnik
MVC means a ton of different things. Django itself does not use "MVC" to
describe itself: [https://docs.djangoproject.com/en/dev/faq/general/#django-
ap...](https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-
be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-
template-how-come-you-don-t-use-the-standard-names)

> If you’re hungry for acronyms, you might say that Django is a “MTV”
> framework – that is, “model”, “template”, and “view.” That breakdown makes
> much more sense.

~~~
misiti3780
models -> models.py, controllers -> views.py, views -> templates,

right?

~~~
kitanata
It's all semantics. As a long time django developer (4 years) I agree.

------
tracker1
Just want to point out that MongoDB doesn't have full text search perse, but
it can do nested array indexes... If you want stubbing/phoneticization you
need to do it as part of your input, and part of your search logic... if you
front your queries with a service then it is easy enough to do.

~~~
mathias_10gen
Actually, as of 2.4 there is an experimental text search feature built-in:
<http://docs.mongodb.org/manual/core/text-search/>. While it is no Lucene (and
is still considered experimental) it does provide simple tokenizing, stop-
words and stemming.

------
domrdy
I tried various asset management tools but prefer having grunt manage all
frontend related things. Node projects seem to be better tailored for this.
Especially stuff like linting and watching for code changes, plus having a js
based config file for people that don't speak python.

------
fduran
nginx with uwsgi is also an excellent alternative imho

------
boerni1234
"Use named URLs, reverse, and the url template tag": For Javascript URL
handling use sth. like that <https://github.com/version2/django-js-reverse>

------
Pxtl
That is an impressively long lost of tools to pick up and get running
professionally on top of being a web newbie. Hat tip to that man.

~~~
misiti3780
~ 2 years and a lot of pinot noir ....

------
mhahn
solid list, I would also add that it is extremely useful (I would argue
necessary) to use vagrant (<http://www.vagrantup.com/>) to manage your
development environment.

~~~
misiti3780
this is actually on my todo list, i saw this video by zac holman a while back:

<http://zachholman.com/screencast/vagranception/>

and have been meaning to mess around with it ever since

------
unwind
Why does this page break "space" for paging down (in Firefox 20.0.1, Windows
7)?

------
smogzer
Replace all comments with: Use web2py instead of django

------
derengel
Is mongodb a good choice for CRUD apps also?

~~~
jaegerpicker
depends on the actual app use. Simple in and out low traffic crud? It's
probably not worth the extra effort. MySQL is still a great product that has
and will continue to serve billions of web requests and just cause NoSQL is a
new kid on the block doesn't mean that everything should use it.

That said if you are storing data that is really just documents, Mongo or
another document db is likely a good choice. For example if you storing
interrelated performance measurements (like in a factory setting ) Mongo would
likely not be the best choice but say in a setting like an app for applying
for a job or registering for events ( natural document data segments ) a
document db would work well for modeling the domain I'd think.

------
schrijver
off-topic, this _Medium_ platform seems to mangle all outgoing urls…

------
the_cat_kittles
using a settings module, requirements directory and environmental variables
makes alot of sense (outlined in two scoops of django at
<https://django.2scoops.org/>, a good book)

