jdunck

It's worth noting that since the collateralized housing debt scandal of the Global Financial Crisis, approximately nothing changed in regulation, and credit card and auto debt securitization has taken off in its place. Investors still want to put their money somewhere.

Who is the Lehman Brothers of the new securitized debt? That meltdown is coming.

And what if the battery weight is nearer axle centerline than an ICE?

If Google (or any other crawler) wanted to play nice with paywalls, they could issue a public key for their bot, and put a signature in their User Agent string that the domain could then verify.

Those signatures could obviously leak, but on a per-domain basis. Perhaps the domains could have a secure way of bumping the valid key generation if they had a leak.

As a general rule, I don't use public wifi and council people to use VPN if they must. No flash, disable java in the browser, prefer chrome to safari, AdBlock and NoScript if you don't need JS.

Could you provide a citation for "automatically jailed for not handing over your encryption keys" - I have not heard that before.

Pre-commit hook should address your concern?

I agree with the premise of judging based on both action and context, power and relationship. I agree that hackers aren't the nerd-revenge underdogs (if we ever really were). I agree that we have power to do good, and we mostly piss it away trying to impress each other.

But I disagree that RIAA and MPAA are totally losing - they still have direct lines to power through the government and its regulative and, ultimately, judicial and military power.

There are more than 2 sides. There is not "the man" vs. "the underdog". It's less chess and more hungry hippos. Yes, we should build something better (for the market, for the world, for the commons) than TPB. But the regulative status quo disallows those things. TPB is a mushroom colony. What you want is a tilled field.

The government does not serve RIAA well, but it also salts the earth where we might grow internet-aware markets. TPB is a compromise solution, and better than nothing.

What we build is not in a vacuum.

Let's get started cultivating the field, plowing under the existing regulation which is defunct and self-serving, erecting new fences where boundaries represent newly-reasonable compromises, advantages, and common sense.

Thanks for showing your confirmation bias. Keep asking questions you don't want to think about.

Because software is eating the world.

Because entrepreneurship creates jobs.

Because software is the new means of production.

Because people different than you have problems which are different than yours.

Because dog-fooding is a great way to make something people want.

Lots more reasons, but chew on those.

That people are reading this subthread and finding common cause with this right here... Do you realize how ridiculous you are?

If you would like to know what racism is and why criticism of a dominant group on the basis of race isn't in, here's one take: https://www.youtube.com/watch?v=dw_mRaIHb-M

But you'd have to listen to get it, and you'd definitely have to give up your bullshit self-serving circular "logic".

I think there's some amount of aptitude, but mostly it's just applying effort over time. Keep going.

I mentor Ingrid through Hackbright, and she's great to work with.

In general I find it really inspiring to be involved with an organization that introduces so many smart and motivated women to the field of software.

Think back to the first time you tried coding, how that happened, how you felt about it, who encouraged you or discouraged you, etc. Unfortunately it happens less for non-white, lower-class, or non-male people. Yes, there is still curiousity, determination, and hard work to succeed in the field, but it starts with that moment where you first believed you might master this skill.

What can you do to make that moment more likely to happen for more people?

That commit was made in response to this incident. No commit process was previously documented.

If we're just plugging useful packages, I'd suggest these as useful and broadly applicable:

    * django-debug-toolbar
    * django-secure
    * django-celery
    * django_compressor

(django core feedback):

Django is not perfect, and will never be. It's now a fairly large codebase, and though there are a bunch of committers, people often feel it's easier to write their own library than push things into core.

Separate from that, some things really don't belong in core - they aren't generally applicable, even if they are valid use cases. We prefer to address minority use cases with extensibility. Rather than saying "your use case is not valid", or saying "give us your kitchen sink", we say: "OK, that's a nice sink - why can't you currently use it? What if we add this valve here?"

In the best (and, I think, fairly common) case, people write libraries, the community finds it generally useful, and the best of that library gets incorporated. We've gained authentication, cache, and migration improvements that way.

There are warts, but the proliferation of libraries are not bloat - they are often a resistance to bloat. Search github for django + jsonfield, and you will see quite a lot of opinions about what it should be. If we'd added the first one that seemed decent, we would have been adding a wart for many people.

I have used all of the recommended libraries before, and while they are nice, I wouldn't call them essential. It works fine without them. Some of the -extensions are very nice, but they rely on 3rd-party libraries, and django has had a pretty conservative dependency policy - python, your database driver, and you're generally ready to go. I think that's a win -- you can add additional dependencies if you want them. Of the libraries, only South is a thing I have used on most projects, and as noted elsewhere in the thread, that's being incorporated into core. As for grappelli - I think the admin needs an update, and we've worked off and on on that quite a bit. Grappelli imagines one direction for improvement, but I don't think it's what core should be -- and I suspect the Grappelli maintainers would agree.

With all that said -- I consider flask roughly comparable to sinatra -- it is smaller, but what parts there are make additional, not fewer assumptions about what you're building. SQLA is a way more powerful ORM than Django's, but I don't often feel limited by Django's. And when I do, there's .raw or .execute. I find SQLA to be overkill for the sorts of queries you'd do in a web request.

If you're saying: you'd rather learn best-of-breed libraries and compose them yourself -- that's a valid point of view, but it's an opinion, not a correct answer for all sites or situations. Since reuse-in-the-large is still an unsolved problem, a thing that falls out of using different libraries and composing yourself is that you lose the community's bounty of components that work with your particular system composition. As for me: I recognize that django is larger and harder to pick up than flask, but I suspect that if you instead (and, IMHO, more properly) compared picking up django with picking up flask, SQLA, jinja, flask-admin, etc -- then they compare favorably in terms of uptake -- and django still gains from the community's many django-* libraries.

django core here, some feedback on -annoying:

It'd be nice if you were clear about what versions of django and python are supported.

From django-annoying's feature list:

    * render_to - seems to be roughly equivalent to django.shortcuts.render
    * signals decorator - now in core[1] (since 1.3)
    * ajax_response - seems useful, though might make sense to check request.is_ajax[2]
    * autostrip - hmm, seems oddly edge case-y, I definitely wouldn't apply it to all my forms
    * get_object_or_None - nifty 
    * AutoOneToOneField - assumes the related model is valid with only the FK filled in, which seems fairly unlikely in many OneToOne cases.  I'm not sure if this was proposed to core, but I'd think it would need some sort of default= fillin feature to be more generally useful.
    * JSONField - soo many competing and variously featureful implementations. This has been discussed a few times; it seems fairly easy to implement and hard to gain consensus. I wish we could get it in core, but the juice doesn't seem worth the squeeze.
    * get_config - I don't think I understand the purpose of this, unless you're just trying to be more intention-revealing than getattr(settings, ...)
    * HttpResponseReload - nifty
    * StaticServer - I don't think I understand why you wouldn't want to config urls.py instead.

[1] https://docs.djangoproject.com/en/dev/topics/signals/#connec...

[2] https://docs.djangoproject.com/en/dev/ref/request-response/#...

By "ID", I don't mean government-issued photo ID, necessarily - just the ability to know how a person is will do.

It may be that the person is a repeat user so that the staff recognizes them, or it may be that someone else can vouch for them. And some will have photo IDs, too. ;)

Lava Mae is not yet operational but I think it's pretty likely that Doniece will use the scheme. If so, I'd be happy to do a follow-up with how it actually worked.

> Do homeless people have a single canonical name that they will use consistently?

They have an identity.

> Is it fair to request that they structure their day around a hashing algorithm that they don't understand?

It is not fair that they are homeless. It is not fair that the best thing for many of them to do is to stand in line starting at 3AM the previous day to get a bed for a night. It is fair to offer them a fair chance at a shower in a predictable way. Rather than standing in line for hours in hopes of a shower, they can come and maybe get a shower... or not. Unfortunately, rationing is necessary.

The tokens idea is interesting, but the meaning of them is a good bit more abstract than remembering a single time. Also, things get lost, and keeping things is pretty hard when you're homeless - basically everything you hope to keep has to be carried with you at all times.

OK, I misremembered, it's a queue, not a deque. Still: http://imgur.com/a/Yujev#0

Also kinda random since we don't use much Java here. I do like that people debugged it, though.

A fair number of homeless have mental conditions, but not nearly all. In any case, the hashing approach doesn't manifest as complicated: What's your name? OK, come at 10:15 on Wednesday. That's all.

You won't believe this, but we actually have a soda fridge here that has a deque implementation on the door with a note that cold ones will be at the back.

I'll provide a pic if demanded. ;)

Well that is super-annoying. I'll tweak the template.

Author here if people have feedback.

Or not sharing passwords between services.

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.

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.

> I'd kill for a solution

Would you code for one? I, too, am sorry that we don't have a thing like asset pipeline. I'm pretty sure it would be welcome...

Regarding 15 - if you want that behavior, you'd be better off with using your own model subclass:

  class ValidatingModel(Model):
    def save(self, *args, **kwargs):
      self.full_clean()
      super(ValidatingModel, self).save(*args, **kwargs)

Then inherit from that everywhere.

Signals have a not-insignificant overhead. They are most useful for tying together code that comes from different places. (If you want to do full validations on 3rd-party app models, then you might this signal approach, but it might also be a bug in the app that the hook isn't just there for you.)