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

Django 1.9 Released

djangoproject.com

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Django 1.9 Released

#41

Post by jsmeaton »

LifeQuestioner wrote: post #38
jsmeaton wrote: post #36

Earlier quoted context omitted.

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 t…

Shame tbh. If they invest they could see their businesses doing even better.

We need to be communicating this to them, quantifying how their business could potentially be doing better, and offering products that they can spend money on. It's that last part that I think most OSS projects are having difficulty with.

Re: Django 1.9 Released

#42

Post by kawera »

jsmeaton wrote: post #36
kawera wrote: post #28

Earlier quoted context omitted.

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.

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 t…

Their need to "buy" something is the crucial point; donations fall in a totally different "account" with distinct rules. Sponsorships may be the ticket but you need to actively reach then as they won't come spontaneously (I think specifically of "that" unicorn :))

Not sure about support, maybe better to leave that to the myriad of contractors that form Django's ecosystem.

Re: Django 1.9 Released

#43

Post by jsmeaton »

jkarneges wrote: post #33

Before anyone says something about Django not being hip enough for realtime stuff, just know that you can layer Pushpin ( 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.

Andrew Godwin (the author of django migrations and south before that) is working on something he calls Django Channels http://channels.readthedocs.org/en/latest/ . The aim is to bring it into core (possibly for 1.10), which will allow real time features.

The traditional request/response cycle will then just become producers and consumers of a "request" channel.

Re: Django 1.9 Released

#44

Post by jsmeaton »

pbreit wrote: post #40
sparkling wrote: post #12

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?

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…

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.

Re: Django 1.9 Released

#45

Post by ipmb »

jkarneges wrote: post #33

Before anyone says something about Django not being hip enough for realtime stuff, just know that you can layer Pushpin ( 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.

I haven't tried Pushpin yet, but we're using the Nginx push stream module on https://botbot.me in a similar manner. It acts as a reverse proxy to the Django app and also handles the realtime connections.

Re: Django 1.9 Released

#46

Post by [deleted] »

jsmeaton wrote: post #11

This might be a good time to mention that Django is always trying to raise funds: 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 comp…

[deleted]

Re: Django 1.9 Released

#47

Post by throwaway_ghj »

ubernostrum wrote: post #39
throwaway_ghj wrote: post #30

Earlier quoted context omitted.

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. 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 pyrami…

This is, of course, why nobody has ever bothered developing a unit-testing framework for a statically-typed language, and why it would have been impossible for the idea of automated refactorings to have originated in a dynamically-typed language.

I didn't claim either of those things.

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.

Re: Django 1.9 Released

#48

Post by iyn »

jsmeaton wrote: post #44
pbreit wrote: post #40

Earlier quoted context omitted.

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…

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…

One can use Custom User Models for things like email logins. I've done this in a few projects and it works great. More info: https://docs.djangoproject.com/en/1.8/topics/auth/customizin...

Re: Django 1.9 Released

#49

Post by ubernostrum »

throwaway_ghj wrote: post #47
ubernostrum wrote: post #39

Earlier quoted context omitted.

This is, of course, why nobody has ever bothered developing a unit-testing framework for a statically-typed language, and why it would have been impossible for the idea of automated refactorings to have originated in a dynamically-typed language.

I didn't claim either of those things. 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…

In dynamic ones you end up writing unit tests essentially for typing

That would be news to me.

Re: Django 1.9 Released

#50

Post by jkarneges »

iyn wrote: post #37
jkarneges wrote: post #33

Before anyone says something about Django not being hip enough for realtime stuff, just know that you can layer Pushpin ( 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.

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/ ), besides not being tied to Django?

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.

Post reply on HN