
Django 1.9 Released - jsmeaton
https://www.djangoproject.com/weblog/2015/dec/01/django-19-released/
======
jsmeaton
This might be a good time to mention that Django is always trying to raise
funds:
[https://www.djangoproject.com/fundraising/](https://www.djangoproject.com/fundraising/)

The really quick turn around on tickets and pull requests is largely thanks to
the Django Fellow, who is paid to manage the community. The last two or three
releases have been on time because of the Fellow. The Fellow is funded via
Django Software Foundation fundraising activities.

If your company is deriving financial benefit from using Django, consider
asking your company to sponsor the fellowship program, so that we can ensure
that bugs are getting fixed, releases are happening on time, and security
releases are being processed as a priority.

(Disclaimer: core member).

~~~
kawera
Good call, this is very important!

It's baffling that such a huge project, used by thousands of companies
including at least one billion dollar unicorn, have such a hard time finding
money to fund only one single developer. As a solo owner and happy Django
user, I've donated what I could and encouraged others to do so but would love
to find a solution to entice larger businesses to donate regularly.

~~~
jsmeaton
The Django Software Foundation has just hired a part time person to organise
fundraising [0]. There is also discussion happening around the community about
trying to find a sustainable way of funding open source projects and Django in
particular.

Part of the problem is that it's hard to get companies to "donate" money. If
they can purchase something like "support" or something else tangible, or
"sponsorship" out of their advertising budgets, there may be more
opportunities of gaining funding.

Thank you for donating though! Django gets a lot of their money from regular
developers' pockets. I, personally, feel that bigger companies using Django to
generate lots of revenue should be contributing a greater portion to support
the stack that supports them.

[0]
[https://www.djangoproject.com/weblog/2015/nov/23/introducing...](https://www.djangoproject.com/weblog/2015/nov/23/introducing-
dsfs-director-advancement/)

~~~
trymas
Maybe I do not know some important details, but why DSF (Django Software
Foundation), does not do Django consulting in the first place. They very
highly likely can do the best Django consulting in the world.

Secondly, maybe DSF could bake some great products for/from Django? The first
ideas I have is Django specific, and user friendly:

\- PaaS;

\- analytics (as in 'new relic');

\- crash and performance logging (as in 'sentry' and/or 'opbeat')

\- CI;

DSF can just simply make business, by making great infrastructure stack around
Django.

~~~
ubernostrum
It's important to remember that the DSF is a non-profit foundation registered
under US laws, which restrict what it can do. Many types of "just act like a
business and sell things" ideas are automatically illegal for a non-profit
foundation.

~~~
dump100
Can they open/own a for profit consulting company, which is taxed as a normal
company but gives all profit/dividend back to foundation?

~~~
jchung
Yes they may. The proceeds of that company would be paid to the foundation.

------
jkarneges
Before anyone says something about Django not being hip enough for realtime
stuff, just know that you can layer Pushpin
([http://pushpin.org](http://pushpin.org)) in front of it. This may sound like
a bandage but it's actually good design, regardless of programming language.

Disclaimer: author.

~~~
iyn
I didn't hear about Pushpin before, looks like a solid product, will
definitely look into it. I'm not sure if that's a valid question, but how does
the Pushpin compare to something like SwampDragon
([http://swampdragon.net/](http://swampdragon.net/)), besides not being tied
to Django?

~~~
jkarneges
SwampDragon is a more comprehensive solution. It comes with a JS client and
lets you define data models. Pushpin is lower level. It has no client protocol
nor client library and handles various push primitives on behalf of the
backend.

If you want to add realtime endpoints to an existing Django project, or if you
want to build an API, then Pushpin may be preferable. SwampDragan may be
preferable for new, non-API projects.

It might be cool to see the two projects integrate somehow, since they
actually sit at different levels in the stack. There could be value in
SwampDragon being able to delegate push responsibility to Pushpin.

------
FabioFleitas
Excited about the new JSONField added:
[https://docs.djangoproject.com/en/1.9/ref/contrib/postgres/f...](https://docs.djangoproject.com/en/1.9/ref/contrib/postgres/fields/#jsonfield)

~~~
Alex3917
I upgraded from hstore a couple days ago. I expected it would take me a couple
days, but it only took two or three hours. I basically just had to replace the
field in the model, and was surprised to see the test suite passing. But it
turns out that all of the application code just magically worked as is. And
it's also a security win since you needed to be a Postgres superuser to
install hstore.

------
jMyles
If you are deploying a new django project, let me suggest hendrix (twisted +
django) as your WSGI publisher.

hendrix makes concurrency simple, fun, and fast using Twisted, which is
battle-tested and experiencing an amazing renaissance of young talent (as
evidenced by the amazing vibes in the Twisted room at the PyCon sprints).

[https://github.com/hendrix/hendrix](https://github.com/hendrix/hendrix)

~~~
jsmeaton
I can't say I've used twisted at all, but Amber had a fairly good talk at
Django Under the Hood this year on this topic:
[https://opbeat.com/events/duth/#twisted-and-
django](https://opbeat.com/events/duth/#twisted-and-django)

------
dudus
I'm curious what the redesigned admin looks like, does anyone have
screenshots?

~~~
jsmeaton
It's CSS only changes to be backwards compatible.

Here's a screenshot I dug up from google.
[http://imgur.com/3xGdZ04](http://imgur.com/3xGdZ04)

The changes were originally released in a 3rd party package:
[https://pypi.python.org/pypi/django-flat-
theme](https://pypi.python.org/pypi/django-flat-theme) that has some
screenshots too.

------
mangeletti
Thank you everyone who committed their time and code to this release.

------
rafaquintanilha
This is still better when you are able to experiment versions without quirks
and workarounds. Hail virtualenv.

~~~
olau
Django is really easy to deploy manually too.

Download the tarball, untar it, make a symlink from inside your project dir to
the "django" subdir. If you want to try another version, you just change the
symlink to point to the other version. If you are curious which version you're
running, you can just do a "ls -l" in the project dir. That's it.

------
japhyr
I just got around to skimming the release notes, and I'm curious about running
tests in parallel. I'm looking forward to upgrading, and seeing if this has a
meaningful impact on my tests. I don't have a large number of tests yet; my
project runs its full test suite in ~10 seconds at the moment. But I'm well
aware this should grow significantly as my project matures.

Does anyone have any sense yet of how this affects the speed of the test suite
in your real-world projects?

[https://docs.djangoproject.com/en/1.9/releases/1.9/#running-...](https://docs.djangoproject.com/en/1.9/releases/1.9/#running-
tests-in-parallel)

~~~
cscharenberg
Massive speedups once you get to thousands of tests. We 12 minute runs for the
3 apps that are part of a release. When we went parallel it reduced it by 1/6
(6 test processes).

Of course, we also had some slow tests we rewrote and had to fix some tests
that did not play nice concurrently. But it was well worth it.

I don't think you'll see a big benefit for a current 10-second run because of
fixed cost of startup is some of that. But running tests in parallel may
reveal some bad testing practices: leaving data behind or improper mocking
that cause tests to fail in parallel. Fixing all that once you get to a
massive set of tests is really painful and slow becuase you have to fix them
ALL before switching your testing config. So that might be a benefit to
turning it on soon and growing your tests already in an parallel environment.

~~~
japhyr
Thanks for the thoughtful response. I appreciate the perspective on what it
means for large test suites, and why it's beneficial to think about this in
early development stages as well.

------
snogglemedia
Is the Django team planning anything big for a 2.0 release?

~~~
ubernostrum
Expanding a bit: the plan is that 2.0 just switches us to a new versioning
system. The tl;dr is:

Versions start going 2.0, 2.1, 2.2, then 3.0, 3.1, 3.2, then 4.0, 4.1, etc.

Every X.2 is a long-term support release.

The deprecation cycle gets tweaked so that if you're on, say, 2.2 LTS and your
codebase runs with no deprecation warnings, then you'll be able to just run
as-is on 3.2 LTS. You can then clean up any deprecation warnings on 3.2, and
you'd be good to go for 4.2 LTS, etc.

~~~
Scarblac
And as a special case of that: according to the current roadmap, 1.11 will be
the last version to support Python 2.7, 2.0 won't.

------
theli0nheart
Music to my ears! I literally just installed 1.9rc2 thirty minutes ago.
Congrats to everyone involved in the release.

------
sparkling
Not looking to start a fanboy-war here; but i would like to hear some
opinions. If you were to start a new small to medium sized web app today,
would choose Ruby on Rails or Django?

~~~
pbreit
I'm shocked, frankly, at how lousy both are out-of-the-box. I just don't get
why a simple CRUD app (which many/most apps are) has to be so difficult. I had
trouble figuring out how to do email login on Django and just gave up. At
first, Rails seems like it's going to be a lot better. I don't care for
generating files. Don't like TDD. And found the migrations very confusing (if
I make a typo in a field name, I delete the whole project and start over).

I can't believe this is the current state of web app development. I know
everyone's moved on to Node and Angular, but, c'mon!

~~~
jsmeaton
Unfortunately it looks like you hit a bit of a sore spot with regards to
django auth. There isn't a good out of the box solution for email based
usernames. There are patterns available, and the "swappable" user framework is
there to allow email based usernames. But an email based model isn't
available. I'm fairly sure there are tickets or ideas to make this happen, but
we're not there yet.

Django really is quick and easy to get going though. If you can make your way
past the email based usernames, I think you'd find a really capable and easy
system waiting for you.

~~~
Alex3917
I think a bigger issue with regards to usernames and email is the fact that
neither are titlecased before getting indexed. I get that there are certain
legacy considerations or whatever, but it really seems like there should at
least be a note in the documentation about this given the massive clusterfuck
that would potentially ensue should someone not figure this out before
launching.

~~~
jsmeaton
Do you mean that usernames/emails aren't normalised to a single case to
prevent "duplicates" of "jarshwah" and "Jarshwah"? If so, this was recently
brought up on the mailing list:
[https://groups.google.com/forum/#!topic/django-
developers/SW...](https://groups.google.com/forum/#!topic/django-
developers/SW7_qI81G58)

I agree this should probably have a solution or at least documentation to be
wary of.

~~~
Alex3917
Yeah, I actually hadn't seen that, but I know there are also longstanding
tickets for this. I actually don't like the solutions in those threads, I
think better to just add an extra field to the models, so have something like
'db_email' and 'display_email'. I realize you can do this with a functional
index or whatever, but I think that's actually kind of hacky given the lack of
ORM support for functional indexes.

My big issue with the current state though is that if you're relying on
usernames or email addresses being unique then you're potentially opening
yourself up to all sorts of security issues without realizing it.

~~~
jsmeaton
FWIW I agree the solutions in that thread aren't good enough, especially since
most of them are postgres specific. Now that migrations can be shipped with
contrib.auth, a better solution might be possible.

I'd probably prefer a functional unique index since it would be easier to
maintain (rather than duplicate fields). We just need to get expression
support into indexes.

~~~
ubernostrum
Well, I hear there's this expressions API and that now it's possible to use
them during the initial creation/save of an object... maybe there's some
normalization people could do with that :)

------
cdnsteve
Parallel tests, curious if folks are seeing a big difference in their existing
testing suite?

On_commit sounds nice.

------
collinmanderson
This is the second perfectly on-time major release in a row. Way to go team!

------
johndevor
What does the new admin style look like?

~~~
collinmanderson
[https://docs.djangoproject.com/en/1.9/intro/tutorial02/#ente...](https://docs.djangoproject.com/en/1.9/intro/tutorial02/#enter-
the-admin-site)

