1,562 karma · joined November 23, 2016
If it's an unnecessary mental load (for developers or managers) to find out about the tasks currently being worked on and what they are, then the problem is with your work/task tracking system, not with your developers.
It doesn't mean it has no value as a wild, natural environment, just that from an economic development perspective there's not a lot going on there.
Which is probably fortunate for all the other players since all of the Autopilot issues get attributed mainly to Tesla rather than to self driving cars.
It's actually one of the more interesting challenges of beacon (and QR) adoption; most of the obvious/easy to implement use cases are already well supported by GPS
If the musician was able to provide enough capital/resources on their own by risking their entire livelihood they'd have no need for an investor and could take the entire profits of the venture for themselves.
I'm not making a moral judgement here, I'm just saying that it's a fairly straight forward logic as to why people who "only contributed financing get a bigger cut". The OP is wrong to claim they get a bigger cut because they're already rich, they get a bigger cut because they're risking more capital in the venture. It is secondary that them being rich means they have more capital available to take risks.
I don't think I've ever seen someone claim to use Linux because it's free (no cost). It's almost always because it's an open platform or because it has the best tools for the job they're doing (e.g. development work).
So in that sense, a Linux user might be less likely to use a product if they care most about the openness of the platform.
Their exact cut is generally a balance between the risk, reward, and ability of the venture to happen without them.
As a game developer your job then would be to write interesting enough systems for players to exploit to come up with interesting gameplay. I can imagine a scenario where different Overwatch-style "classes" emerge all built from the same basic game elements.
It's actually an interesting challenge when it comes to mobile. A number of things that could be handled with NFC (and QR, beacons, etc) end up being implemented using GPS and the phone's network connection.
I've given up running Linux natively on my computers and I'm trying to find the best Windows 10 workflow
The parent didn't understand why developers would be happy that React got the greenlight. My response was that React (and Vue) really is a much better tool for building interactive websites than many older tools like jQuery.
React (and others like it, e.g. Vue) really is a huge win and solves a ton of pain points common to front end development. It still has its own pain points, but it's hard to overstate how much of an improvement it is over other older approaches like jQuery.
Apple could do the same thing with maps. Support a robust open mapping initiative to make sure their primary business (selling iPhones and other devices) has a solid platform for emerging technologies like AR. Making sure they have a solid maps offering supports the Apple (aka iPhone) ecosystem.
Also similarly to Google, they can still push plenty of proprietary things on top of the open parts of the initiative.
`if (foo) { return true } else { return false }`
is the same as `return boolean(foo)`
It would be far better to state the metric they're using, i.e. "GitHub Stars !== Usage: React downloads still surpass Vue and Angular"
It's taken React about 2-3 years to go from being head to head with Angular(JS) to being the dominant frontend ecosystem. I expect within 2-3 years Vue and React will be on far more equal footing in terms of usage and jobs. (Assuming something else doesn't come along and topple the current trend towards reactive frontend tools.)
There's no proof yet that self driving cars are safer than human drivers. And more importantly there's a big difference between being safer on average than a human driver, and being safer than the average human driver.
DRF is great for making APIs, authenticating and talking to the APIs with Vue is super easy and straight forward (I recommend using Axios and writing service files in Javascript to encapsulate the logic for actually calling the API.
The main pain point is that Django is kind of unwieldy to deploy, because you'll have your built Vue project (i.e. the dist/ folder by default), and then you'll have the collectstatic files from Django, so setting up a build process that combines all of that is a bit difficult.
The first 90% of the work takes 90% of the time. The remaining 10% of the work takes the other 90% of the time.
Not saying they're right or wrong (I think at the very least it's a limited point of view) but that's the argument being made.