I know the are well, and let's just call it Walkable. For comparison, I moved from the suburbs of Houston (14 walking score) to the Montrose area (94) for the same reasons why I live visiting Manhattan - not having to drive most of the time.
Chao's comment is right on. Living in your own pocket is great, but driving to the article's house still takes 20-25 minutes since it's all interior roads.
1. Suppose you have contributed to projects A, B, C, D, and E.
2. When someone looks at your profile, they see A, B, C, D, and E listed in a vertical list, apparently sorted by how many contributions you have made to each.
3. You decide that you want the world to know you disavow your contributions to one of these, say, B.
4. You fork the project disavow/above-repository.
5. You make a branch, make some commits, and push them, and then make a pull request. Apparently disavow/above-repository will accept your pull request.
6. disavow/above-repository then appears in your contributions list.
7. Keep making commits to move disavow/above-repository up the list until it is between B (the project you wish to disavow) and C.
8. Now when people look at your contributions list, they see:
I'm not sure what you are supposed to do if you want to disavow a second repository. Maybe they need to make a disavow/below-repository project too.
The idea of disavowing contributions is an interesting one, although it is probably something best handled by convincing Github to support a mechanism for it. More generally, it could be useful to have a mechanism to explain your relationship to a repository you have contributed to. On a project page, you should be able to view the explanations from all the contributors, and on a person's profile, the list of projects they contributed to could also list their explanation.
We've been rebuilding a major app in Node and searching for validation solutions that would support async.
Embarrassingly, very few Node validation libraries support async!
This makes it annoyingly complex to have multiple sets of validation on the server to ensure a new user is indeed a new user, that foreign keys match their constraints, etc. on top of the dumb type checks.
The fact is, there's always a new tool for the job a year or two down the road, but software needs building today.
I launched a major internal admin a year ago with Angular and it's largely on autopilot because Angular is so darn easy to work with when it comes to building new features, especially in the view layer.
I've done several BBQ tours on my monthly trips from Houston to Austin, and Salt Lick consistently requires a fork.
The half-dozen times I've had Franklin's BBQ, I've witnessed the brisket slab wobble like jello, and can't help but describe the moisture as butter-esque. Seriously, that stuff is so rich you can't eat it often at all.
Still, I've found that even in Texas everyone argues over which bbq is better. Some argue against any sauce, any forks, or anything to imply the meat is less than perfect. I've even had pitmasters argue that tearing at a rib bone with your teeth because the meat is dried on is "correct", and fall-off-the-bone is over/undercooking.
At the very least, Franklin's is different from Rudy's is different from Salt Lick is different from whatever.
It's all preference, but one thing you can bet on is good BBQ will have a good line :)