wylee

I think the reasons are more practical. It's rare that it rains very hard in Portland. Carrying an umbrella throughout six to eight months of the year just in case is inconvenient, and you'll probably end up losing it anyway. A light rain jacket is easier to deal with and also blocks the wind. I don't think pride has much to do with it.

This PSU site may be of interest to anyone who's made it this far into the thread: http://neighborhoodpulsepdx.org/. It has some charts and maps that explore some of the data relating to population growth in the Portland area.

Edit: This is probably a better direct link: http://neighborhoodpulsepdx.org/portland21/growing-portland/...

I don't think anyone does `git bisect` all that often, but... when you need to do it, you hope the history is clean. Otherwise, figuring out what went wrong and where can be a nightmare.

I just went to one of my repos on Bitbucket, and it only took me one click to get to the source for master and then another click to get to the source for another branch.

You can also set up a project so the source is shown by default on the "landing page" instead of the overview.

Edit: slight re-wording

The main reason I prefer a lighter bike is for when I need to carry it up some stairs or something like that. For most everyday riding I don't think weight matters much.

I would think that when someone writes a document like this that the context is really important for the record and that they're not so concerned with making an "impact".

Edit: Grammar

I initially only glanced at the about page without reading it, but after I saw your comment, I went back and read the whole thing. Most of it is just (interesting IMO) info about the site and the technology behind it.

Or, at a higher level, maybe their approach to soliciting candidates is wrong. A lot of the job descriptions I see are sloppy. Or they're so vague that you can't figure out what you'd actually be doing (or what the day-to-day would be like). Some of them throw in peripheral technologies just to cover all the bases or something.

It seems like a lot of hiring managers/companies treat a job description as an afterthought when it actually has a huge effect on who applies for a position (_obviously_). People who have more options will tend to ignore the sloppy, vague postings.

The person who wrote this article seems more conscientious than this, but it's something to consider.

I use DRF with Angular at work, so I'm interested in seeing where this series goes.

Tangentially, I can't imagine using Django without DRF. It makes setting up RESTful(ish) APIs so easy. Even if you don't care much about the RESTful aspects, it provides a much nicer way to organize your code than default Django IMO. I especially like how serialization works versus Django forms.

Good point. I'm not sure off the top of my head if Shapely has a specific function for what you're trying to do. It does have highly-optimized distance functions though. Might be interesting to compare those to your version.

One way I've approached this problem that seems pretty fast is to load a set of points into a PostGIS-enabled database, then use the `ST_Distance` function and order by distance.

[Edit]

Shapely solution:

    points = MultiPoint(((0, 0), (1, 1), (4, 4)))
    point = Point((3, 3))
    sorted(((p, p.distance(point)) for p in points), key=lambda item: item[1])

What's really bizarre is that they actually deliver the article content in the initial HTML response. It's just hidden using CSS. You can read it by turning off CSS for the page.

I guess it's kind of beside the point of the article, but I wonder if the author considered using a library like Shapely[1].

[1] http://toblerity.org/shapely/manual.html

I personally think it's best practice, although returning a generic 400 isn't _that_ bad. Libraries like Django REST Framework handle this automatically.

I have family in the southeastern US who use "anymore" like the person you're responding to did (and they have for decades). I don't think it simply means "now". There's a slightly different connotation that seems somewhat negative. Kind of like: "It used to be like this, but now it's like this... and I'm not sure I approve".

> This is reassuring for those optimists out there, as it suggests that people are often honest even when they don’t have to be.

Or it could be that people don't realize there's no way for the experimenters to know if they're cheating, so they're on their best behavior until they become familiar with the system.

I think this is true in a lot of domains (jobs, dating, etc). In the beginning, people follow the rules. When they're comfortable with the ins and out of the system, they start gaming it.

It sounds like you and the person you responded to are saying that there were self-driving cars in the year 2000? There really aren't even self-driving cars now, in 2015. Sure, there are prototypes (which are really cool), but there's a big leap between a prototype and the average person owning/hailing a self-driving car.

I think the shift to self-driving cars will be more of a social/cultural/political challenge than a technical one. I might even go so far as to predict it will never happen (at least, not for average people getting around town).

I don't see anything wrong with cynicism _per se_. In fact, I have a hard time seeing how it's possible to avoid becoming at least somewhat cynical. Apathy and complacency on the other hand--those I have a problem with.

On the other hand, I'm not sure it's fair to come down so harshly on people who are feeling hopeless and/or powerless. I'm not sure getting indignant with such individuals is particularly constructive. There's probably a reason there are so many people who feel this way, and it's not just pure selfishness.

Your example isn't very compelling, but for longer strings with more complex formatting, I'd say .format() is pretty compelling. I find that in general

    '{x} blah blah blah {y}'.format(x=x, y=y)

is more readable than

    '%s blah blah blah %s' % (x, y)

even if the former is a bit longer.

On top of that, there's a whole bunch of stuff you can do with .format() that just isn't possible with %.

Cat Purr is one of my favorites. I blend it with one of the water sounds, which effectively blocks out most office noise and creates a calm, soothing space.

Also, my cat freaked out a little when I played it for her.

Agreed. I can't pay proper attention when I type notes on a laptop during meetings. And it would seem that other people can't either. I scribble notes on a notepad and then transcribe them after or create tickets from them.

I've noticed that people often get caught up editing and formatting while typing (especially when the screen is shared), whereas with notes, people don't worry so much about that, so it's easier to stay focused.

> Free markets when supported by strong property rights can have strong protections to prevent harm or pollution.

This seems to imply that such markets aren't actually "free" since they're regulated via the enforcement of property rights.

I mostly use GitHub these days (at work), but I think Bitbucket is pretty similar in terms of features and may even be better in some ways (e.g., I like Bitbucket's design better, and they give you unlimited private repos). I don't think you could say GitHub is miles ahead of Bitbucket, except maybe in terms of users.

Regardless, I agree that more competition is good.

I'd guess the scenario is more like a social setting where you know some of the people and don't know others. And you're having a "what do you do?" kind of conversation where you respond with "computer stuff" and then the person you're talking to, or someone in earshot, says something like "Oh, maybe you could help me with mine...".

That's happened to me several times. I've also had people do a similar thing in work settings--people who weren't even direct coworkers.

I agree with you, but only for local commits that haven't been pushed to a shared repo.

Rewriting local history seems no different than rewriting code in your editor.

Rewriting shared history is (almost) always bad.

> The obsession of git users...

That seems overly broad. It seems to me that most people who use git agree that public history shouldn't be rewritten, especially on master.

> The whole point of history is to have a record of what happened.

On the other hand, a bunch of "Derp" or "Whoops" type commits aren't very useful. It's definitely beneficial to clean that sort of stuff up by rewriting local history before pushing.

Everything in Python is an object:

    >>> isinstance(type, object)
    true
    >>> T = type('T', (), {})
    >>> isinstance(T, type)
    True
    >>> isinstance(T, object)
    True
    >>> isinstance(T(), object)
    True
    >>> isinstance(int, object)
    True
    >>> issubclass(int, object)
    True
    >>> isinstance(1, object)
    True

That doesn't seem funky to me, given that `x` in your example is in fact not local to `inner`. It may seem surprising, but it's consistent with how Python handles locals in general.

Did you factor in the energy that goes into producing vehicles, building & maintaining roads, etc? Or did you just count tail pipe emissions? What all factors did you consider when assessing the impact of the fleet?

I'm not sure what your use case is, but you may want to look at serializers.RelatedField.

> I wonder how often it actually comes into play

I've wondered the same thing in the past, but just recently I converted two Django projects at work from MySQL to PostgreSQL. The transition was pretty much seamless--I didn't have to change any application code.

One of the projects was converted to add spatial capabilities via PostGIS. The other was converted due to an issue with how MySQL stores data (it ended up being easier in a time crunch to dump and reload into PostgreSQL than fix the issue with MySQL).