Django 1.9 Released
djangoproject.com
djangoproject.com
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).
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.
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...
I'm wondering (and of course I know little about this) if it would work doing things like: - community voting on the direction of the project or new features to be added and the top 5 get selected if there hits say 50k votes. - costs say 2-3 dollars to cast a vote. But if it's enough cash it means it won't dictate the direction of django by money or businesses and some of the cash can be spent elsewhere not just on those top 5.
So a feature could be something like "seamless upgrading from 1.8 to 1.9" which businesses might want or be willing to pay for.
Not sure about support, maybe better to leave that to the myriad of contractors that form Django's ecosystem.
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.
I love open source software, and I want to see more high-quality open source. I want to see established projects like Django continue to thrive. If you're curious about how funding impacts the quality of open source projects, you might want to check out Russell's talk.
[0] - https://www.youtube.com/playlist?list=PLs4CJRBY5F1KMMpoEWMuB...
[1] - https://www.youtube.com/watch?v=mY8B2lXIu6g&list=PLs4CJRBY5F...
Disclaimer: author.
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.
https://github.com/AppEnlight/channelstream
It's gevent based and supports websockets and long-polling, by design it integrates with any kind of application for real-time broadcasts, be it django, php, cron scripts etc.
The traditional request/response cycle will then just become producers and consumers of a "request" channel.
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).
Here's a screenshot I dug up from google. http://imgur.com/3xGdZ04
The changes were originally released in a 3rd party package: https://pypi.python.org/pypi/django-flat-theme that has some screenshots 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.
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-...
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.
There are still some big ticket features that various people want to work on. These get released as they become ready. There may be some feature that is targeted for 2.0, but we won't know what until after 1.11.
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.
If you like Python, Django.
Both are full featured with active communities. The 10,000ft view of each is very similar.
Rails is built with a "convention over configuration" philosophy. Rails apps tend to look similar whereas Django apps tend to be setup in a number of different ways. The downside of Rail's "convention over configuration" setup is that devs can get things up and running fast and then get frustrated and lost if something breaks....but it's really not that hard to dig around the code. With Django new devs get lost first and figure everything out. After a few months of heavy use and breaking things you won't notice much of a difference between the two. I find rails a bit easier to work with but I like python so I use django/flask.
If you're familiar with both, and have no clear preference, the question becomes a lot less clear-cut.
It made debugging issues much easier than in the equivalent Ruby on Rails project (I tried to build the same proof-of-concept using both frameworks.) When something broke in Django I could usually just follow the code to find what was wrong. With RoR sometimes I would put stuff in some place, expect the framework to pick it up (convention-over-configuration) and the code wouldn't work. Much head scratching ensued.
I wouldn't use either.
Edit: added the following...
I've dabbled with both, and they suffer from the same kind of problem that all frameworks on top of dynamic languages suffer from. You essentially have to do all the checks that the compiler /should/ do for you, by using unit tests. That gets old fast. Also, on large code bases, I now prefer having real refactoring support.
I'd rather pick something on top of a compiler that is not brain dead.
If I had to do python again, I'd use pyramid or flask, and if I had to do ruby, I'd look at Sinatra.
I stand by my original statement, on the basis that both of the offered frameworks are built upon shaky ground to start with.
I'd rather pick something on top of a compiler that is not brain dead.
If I had to do python again, I'd use pyramid or flask, and if I had to do ruby, I'd look at Sinatra.
I stand by my original statement, on the basis that both of the offered frameworks are built upon shaky ground to start with.
I'm just speaking from the practical experience I have.
It's just that in static languages, you write unit tests more around business functionality. In dynamic ones you end up writing unit tests essentially for typing and stuff like that. And, you know, you have tooling so you can actually perform the refactorings at scale across the code base. Like real tools, that the rest of your team know how to use, and your business can hire another person from the same hemisphere to work with after you've moved on.
The tooling around static languages is generally stronger. I've written very similar types of code in both Java and Python, and hands down, I've found it easier to develop and maintain in big code in Java.
I still script quick stuff up in python for personal use.
YMMV.
That would be news to me.
With that said, if you want something up & running asap, pick whatever you're good with and if you want to learn, pick whatever you didn't use before. Django and RoR are comparable.
That said I'll take a stab with it, as I've worked with both. First off they're both MVC frameworks that prioritize a fast, convention-first, development cycle. They both are very well proven, they both have great documentation, and they both have a large number of resources detailing nearly every aspect of their deployment.
So for me it is really a question of these three things:
* what your team is used to
* what resources (capital to buy talent if need be, time to invest in research, etc.) are available to you
* what edge-cases your app might come across over the development cycle (do you need real-time features? might you use a niche data-store? do you have to connect with particular third-party services?)
For each of those points you need to do some planning and decide what the answer if for your team. I believe if you have a grasp on this the answer will be some what evident to you. If it's not, then I think you can just flip a coin because it won't matter to you.
(scientific) Python is definitely better at stats out of the box than Ruby is though.
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!
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.
[0] - https://github.com/pydanny/cookiecutter-django
[1] - https://github.com/pennersr/django-allauth
[2] - http://django-allauth.readthedocs.org/en/latest/configuratio...
I agree this should probably have a solution or at least documentation to be wary of.
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.
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.
1. https://docs.djangoproject.com/en/1.9/topics/auth/customizin...
And I don't see how assertions like this can be made: "This will usually be a username of some kind, but it can also be an email address"
Except for HN, Twitter & Reddit, are there any services that don't use email for login?
I guess sites that use the username as a form of identity within a site. Email address usernames are just identifiers and contact information, without really being linked to an identity.
I would think if auth was being written from scratch it'd probably default to email based usernames. That ship has sailed though.
Which meant that Django's database models couldn't migrate.
Even now, there is no real way to start with Django's own User model and switch your project over to a custom one later (because you'd have many database tables with foreign keys to the Django one). The current recommendation is to start new projects with a custom User model always.
However, you can use Django AllAuth (https://github.com/pennersr/django-allauth) to achieve an email login system by tweaking its settings.
Specifically:
ACCOUNT_AUTHENTICATION_METHOD = "email"
ACCOUNT_USERNAME_REQUIRED = False (if you do not want to use the username field)
More here: http://django-allauth.readthedocs.org/en/latest/configuratio...
Cheers!
In Django's case I would say their Authentication model was an opinionated choice that has since become a major staple of Django. Many frameworks will not include default ORM-models and will instead defer to the user to implement their own authentication scheme.
Personally I disagree with this choice, I think database schemas have to be flexible and an in-framework authentication setup will only encourage users to lean more on the framework even when it is working against them. I've burned plenty of hours in Django trying to work / extend the authentication model. While I have no doubt much of this was due to my inexperience with Django, there is a certain responsibility with having a framework used by many beginners who will struggle and perhaps pick up bad habits (like expecting your web framework to automagically solve everything) if you do not design it for them.
Overall I think Django is awesome. But it's not for every use-case, or every developer. About a year ago I moved over to NodeJS professionaly, some day I will perhaps go back but have yet to have any significant reason to do so.
On_commit sounds nice.