jacobian

Why?

My experience has been that the easiest method is to to upgrade one minor release at once (e.g. in your case I'd do 1.11 -> 2.0 -> 2.1 -> 2.2 -> 3.0). This has almost always gone quite smoothly, but it is somewhat tedious.

That said, jumping a bunch of releases (e.g. 1.11 -> 3.0) actually often works out just fine, especially if I've got good test coverage. It's just that when it doesn't work, it can be tricky to find out what's going wrong. That's because the release notes are typically written with just a single step in mind, so with a bunch of releases I find myself scrambling to figure out which set of notes I need to read.

I would love to read a blog post covering how to do this!

My experience has been that it's significantly more effort to meet my requirements with Docker, and that I spend a _lot_ of time waiting on Docker builds, or trying to debug finicky issues in my Dockerfile/docker-compose setup.

I'm sure all of these things have fixes -- of course they do! But I find the toolset challenging, and the documentation difficult to follow. I'd love to learn what I'm missing, but I also need to balance that against Getting Shit Done.

Ha, I'd forgotten about that. Thanks for the reminder.

(Though, how'd you find that? Mildly creepy that you know more about my dotfiles than I do!)

> the feedback you get is minimal

I've been in hiring roles for 15+ years and I've interviewed somewhere around 1000 candidates. I don't work at Stripe, but I can probably explain why you didn't get feedback.

Giving candidates feedback is really fraught. First, even honest feedback is unlikely to be satisfying. It's entirely possible that your recruiter told you exactly what the team's feedback was. "Your answers were fine, but we want better" or "... but candidate X was stronger" is super-common, but very unsatisfying. Second, while some candidates take feedback well, most don't. When I've been specific -- e.g. "your answers to questions about software architecture fell short" or "you didn't clearly demonstrate experience solving production issues" -- most candidates argue or get angry. People are really, really bad about taking criticism well. I've even had two candidates threaten to sue me, and one threaten violence. These are obviously outliers, but they do happen.

Finally, the upside is limited: to the company, what's the value of feedback? We've already decided you're not a fit, so what value is feedback to us? Especially if, as I've explained, you're unlikely to get much value from it either?

The best way to get feedback about your prospects as a job candidate isn't from someone a company you're interviewing with. Instead, ask someone you trust to conduct a mock interview with you and give you feedback. You'll be more to be able to listen if it's someone you know has your best interest in mind; they'll be more likely to give honest feedback if they know you'll take it well.

Thank you! The new auto reloader is better by quite a bit. Many people have talked about doing this over the years, but nobody's been willing to do the grunt work and figure out all the corner cases, until you. Nice job!

Hi, former BDFL here. It's a crappy job. A crappy, unpaid job. I can't think of a single qualified person in the Python community who'd want the gig. (I can think of several unqualified people who would, and that's part of the problem too.)

> It's hard to drive non-incremental innovation without a benevolent dictator model.

Hmm, dunno that this is a universal truth. Most of the biggest improvements to Django came after Adrian and I stepped down and we moved to a more democratic leadership structure.

I assume you have some standards of behavior, though, right? If a member of your group, say, punched another member, you’d probably kick him out, right?

If so: you have a code of conduct, you just don’t have a _written_ code of conduct. You’re relying on the relative homogeneity and shared context of the group to know and follow the unwritten rules.

This tends to work ok for smaller more homogenous groups with shared social values. But unwritten rules fail for people on the margins, and falls apart at scale.

Can you expand on why donating to state offices is more effective? And, which states?

You may want to check out Invoke (https://github.com/pyinvoke/invoke); it's the successor to Fabric, and it's Python 3 compatible.

> IaaS providers don't do blog posts proudly declaring that they now support 3 year old technology.

http://aws.typepad.com/aws/2013/07/elastic-load-balancing-ad...

How, exactly, is one supposed to cite unpublished research?

1) I know the difference between sessions and logging in. I didn't say anything about logging in; I said that our CSRF protection protects users without sessions. Not all sites use sessions (some for performance reasons, others for privacy reasons); must those sites be vulnerable to CSRF?

2) First, you should report this to Bitbucket: https://www.atlassian.com/security. And c'mon, disclosing a possible CSRF vulnerability on a public board is kinda irresponsible. Is responsible disclosure not something you practice?

SecondI don't know what Bitbucket is running, exactly, and exrapolating from Bitbucket to Django is pretty lazy. Frameworks != sites. Once again, we've spent quite of bit of time validating the design and implementation of Django's CSRF protection, and we believe it works. If you find proof otherwise, can you please send it to security@djangoproject.com, and not post it to Hacker News?

Again, we believe that sessions and CSRF protection can be orthangonal (and that there are benefits to doing so). If you can prove otherwise, let us know!

There's also https://github.com/mozilla/django-session-csrf, an alternate CSRF implementation by Mozilla that does use session-linked CSRF tokens. So if you insist on "tokens must be session-linked", you can use that instead.

Yes, that's correct, in theory BREACH can be used to target any sort of secret embedded in the body of an HTTP response. CSRF tokens are the most common type of secret in that category, but there are others. However, we can't speak authoritatively to The Web or All Web Frameworks or anything, but we can advise our users on how they can protect themselves.

To your second point, security@djangoproject.com. It's documented in a bunch of places; where'd you look for it? I'll add it there, too :)

To the first point, we believe that Django's CSRF protection is as strong as session-linked CSRF protection, and adds CSRF protection to anonymous users (users without a session as well). In other words, it's a design decision, one that we believe doesn't compromise CSRF protection. If you believe otherwise, please get in touch (see above).

I have anecdotes about how CoCs have improved communities, but I don't really want to play dueling anecdotes with you. It sucks that you've seen Coc's used as a bludgeon; I haven't.

However, it's sorta irrelevant here: we're not expecting this to really change much of anything, and we don't think the community needs improving. Like the FAQ says, "we know that the Django community is open, friendly, and welcoming. We want to make sure everyone else knows it too." The goal here is to articulate and write down the standards that we already basically follow but have been (until now) unwritten.

In fact, if you're worried about having the book thrown at you, you should be happy about this change. Before today, if I thought you were being a jerk, I could throw you off IRC or the mailing list or whatever and that was that. I was, until a few hours ago, essentially sole arbiter of standards in the Django community, and those standards were ones that basically lived in my head until earlier this year.

Now, those standards are written down, and there's a process and some oversight to make sure I don't unilaterally decide someone's worth hitting with the ban-hammer.

So really, if you're honestly concerned about being people ousted for violated community policies, this sort of documentation and process should make you feel more comfortable, not less. We're replacing a BDFL-ship with open documentation, a committee, and organizational oversight.

For the record: we reached out to Valerie, not the other way around. We did that because we value her opinion.

It's interesting to me that you seem so angry about a group that's trying to bring more people into tech. What are you worried about, exactly?

You're completely right: these documents articulate a set of standards that we've essentially been following from day 1. Nothing's really changed except that now we've written down the unspoken rules that nearly everybody followed because, you know, they're good people.

It's an "explicit is better than implicit" kinda of thing!

Can you identify specifically what you find patronizing and CYA-ish? Neither were our intentions; help me understand how we've failed there?

Yup, we made a mistake. You could help by submitting a patch to fix it, or you could just choose to be a jerk and give some random person shit for making a mistake.

Your choice.

Mmmm.... I mean, it would, I guess, but I wouldn't recommend using both unless you can show a marked speed improvement over just using pgbouncer. A real connection is (probably) better than persistent connections, so you probably only need the one.

Now, I've not benchmarked this, so it's just a guess. Further, the specific performance characteristics will depend on your specific setup -- particularly upon where you have pgbouncer running -- so the only real answer is to benchmark and see.

New Relic does a good job showing time spent connecting to the db, fwiw, so you may want to give that a try.

Not exactly. It's not proper connection pooling -- for that, you still should be using an external pool like pgbouncer. Instead this is a single persistent connection per thread. The speed improvement should be about the same, but you something like pgbouncer gives you more control over the number of connections and offers a ton of extra features.

We're trying to, yeah.

For this release specifically we wanted to have it out before the end of summer so that we can be ready to merge Andrew's migration work and any GSoC code and turn around another release quickly.

Again, see my comment up-thread. Your assumptions are rather incorrect.

Wow, you're really making a ton of assumptions based on no evidence. I'm sorry you have such trouble assuming good faith.

Fact is, we just forgot to mention it. Django's working so well on Py3 that it kinda seems like no big deal any more, so we forgot to mention it in the release notes. I'll fix that once I get a chance.

Sphinx (http://sphinx-doc.org/), my tool of choice for writing documentation, includes an extension that does this: http://sphinx-doc.org/ext/doctest.html.

Thanks.

I've got to say, this comment makes me rather sad and angry.

Sad, because Two Scoops is a wonderful book. Danny and Audrey spent a ton of time soliciting feedback from a veritable Who's Who of the Django community, and they took that feedback incredibly seriously. The result is a book that does a better job encapsulating how to write successful Django code than anything anyone else has written.

Angry, because of the implied slight against Audrey and Danny. It's sucks that you're too "suspicious" to consider that it might be getting so much attention because it's damned good. When you say that the book is getting "a peculiar amount of attention", it really sounds like you're suggesting some sort of scam. That assumption of bad faith is really offensive -- and completely incorrect. The book's getting attention because it's awesome.

Also angry because of of the implicit demands on my free time that you're making. Writing a book is fucking hard, and I haven't had the time to keep it updated. You're not entitled to my free time.

To end on a positive note, though: the book is getting updated. There's a new author working on a 3rd edition, to be released later this year. I'm not sure if the author wants to be named publicly, but it's someone I know and trust to do an great job.