I'm surprised by the author using Motorola as a historical example of acquiring that went wrong. I thought the goal of acquiring them was for the patents and the sell off was the bits Google didn't want or need.
[
While Facebook and Oculus VR aren't quite ready to reveal a price of the Rift, Luckey suggested that it'll cost more than the $350 developer's kit.
"You know, I'm going to be perfectly honest with you," Luckey said in an interview back in September. "We're roughly in that ballpark... but it's going to cost more than that. And the reason for that is that we've added a lot of technology to this thing beyond what existed in the DK1 and DK2 days."
While $350 may be too low, $1,000 seems to be too high. Elaborating on the Rift's pricing on Twitter recently, Luckey stated that Oculus VR has the backing of Facebook and doesn't need an immediate hardware profit.
"A company that has to survive on immediate hardware profit would have to hit with a much higher price - think $1000+. Not greed, reality," he tweeted. "1st gen VR users are being heavily subsidized by major players who want VR business to grow, though few seem to understand that."
]
Very cool. Like what devhxinc said this is hugely useful. I was not looking forward to trying to decipher let's encrypt at home. I'm impressed how quickly this was put together.
Interesting, confused as to why weather wear is where it ended up? It doesn't seem to talk much about insulation or any of the keep warm themes just general strength.
While the system is definitely a better solution, you also have to look at it from a database performance level. I would prefer the above, and to be honest my knowledge of databases is not strong enough to say that the below makes it impossible or difficult to implement but something that needs to be taken into account.
Spotify currently has a database that tracks the number 'Plays' each artist gets. They then roll that up into a combined number that gives them their royalty payout for the year. Have lets say 100,000 artists, that is 100,000 records accessed when they run their end of year report. On the user level (lets say you have a million users) you now need to keep track of the number of clicks per artist per user. Most likely through having each user have its own click counter table that has a record for each artist they listened to (probably through a foreign key) and then the number of clicks for that artist. When the end of the year report rolls around instead of simply looking at 100,000 records. You are now accessing 1 million records times the average number of artists a user listens too and then running calculations to figure out how much each artist gets by the user. I'm sure there is better database design then the above mentioned but you still run into a more power intensive process to calculate it.
Not something I think will completely stop companies like spotify from switching to this model but something worth considering...
Spotify already tracks user listening history. I can see a "Recently Played Artists" section on my profile, and I assume they're using some of it to generate the user-specific "Discover Weekly" recommended music playlists.
Remote: Yes or In Person
Willing to relocate: No
Technologies: ReactJS, NodeJS, Salesforce, Apex, LWC, Javascript
Résumé/CV: https://mgarf.com/Resume.pdf
Email: opportunities@mgarf.com