k3n
Joined 16 years ago
Joined 16 years ago
> Trump is unpleasant, but at least he talks straight.
You seem to imply that since Trump "talks straight", he doesn't flip-flop?
If that's what you're implying, it couldn't be more inaccurate; he has sharply contradicted himself countless times, straight-up denying things he's documented as saying (on TV, Twitter, etc.)
Possibly not soon, at least from a technical perspective, but I could definitely see a PR fiasco (security, bias, etc.) causing a loss of confidence in its stewardship.
And I don't think it'd be that big of a disruption if it were to happen; for the hypothetical case of Facebook+Yarn, they're already proxying to NPM, so they could easily continue to do so while also accepting packages that are Yarn-only.
See also:
A concrete example would be VSC's git support; out-of-the-box, it's a full-featured git client, and even if you prefer the git cli for most operations like I do, VSC automatically reads the .git directory and then creates a tab that shows your current changelist (modified, staged) with a visual diff of the files. Also allows you to easily do the common stuff like checkout a branch, commit, push, etc.
If you're a big fan of ST, you probably won't like the alternatives unless you have some frustrations with ST, because ST is probably more powerful overall, but compared to Atom & VSC, the learning curve is also quite a bit higher.
> JSON.stringify(1)
"1"
Stored without a decimal for free, seems like it'd be up to the receiver to interpret it correctly.What if you receive it in JS?
JSON.parse(JSON.stringify(1))
> 1
Ok, so it parses an int for free too... thus my confusion.Regardless, you can still override anything it does considering the second argument to both `JSON.parse()` and `JSON.stringify()` allows you to provide your own function for handling the logic as you see fit.
> If it's a core business function -- do it yourself, no matter what.
> Lately, the administrative load has consisted almost exclusively of abuse management.
They see Google Code as a time-sink, and they're probably right, and it's not surprising to me that they'd drop something that is no longer serving it's intended purpose, but instead has negative implications for their model. Keeping it going forward would require even more hands-on humans, so they scrap it.
As for the deep links, one of the Google Code devs did mention[1]:
> I work on Google Code, and we will be putting a service in place to redirect deep links to project homepages, issues, etc. to their new locations.
His comment also contains a link to a wiki with more information on how to opt-in to this service.
http://google-opensource.blogspot.com/2015/03/farewell-to-go...
Her CV begs to differ: she was VP of Search Products and User Experience, and then held key roles in Google Search, Google Images, Google News, Google Maps, Google Books, Google Product Search, Google Toolbar, iGoogle, and Gmail.
I was already leaning towards 'no' regarding the project, but this has sealed the deal.