Earlier quoted context omitted.
I have been working over ideas recently on how to solve the problem of people podcasting in different geographic locations. I think the big problem is latency and audio quality. The audio quality one seems like it is easily solvable with local recordings on both ends adjusted for said latency. The other thing I think would be cool is if with something like the oculus rift you could tune is and sit as the third person…
Out of curiosity, are you using the term "podcast" to refer to something more like a Shoutcast stream? I may be behind the times but I always thought the term "podcast" essentially referred to mp3s (or other pre-recorded audio files) delivered via an RSS-type feed. Kind of the audio equivalent of setting a TV show to record and only watching them as they show up on your DVR. I messed with live streaming audio quite a…
16 Things
121–130 of 135 posts
Re: 16 Things
#122I found a typo on the homepage: "You never need to share the car strangers and we can pick you up and drop you off at your front door." I assume you meant to say: "You never need to share the car WITH strangers..." I love the idea, though. Coming from a smaller town it's pretty hard to fathom a helicopter for hire service ever taking off the ground where I live. So it really made me think! If you can really cut a 2 h…
Re: 16 Things
#123Earlier quoted context omitted.
> We don’t invest in themes; we invest in special founders with breakthrough ideas. Which means we don’t make investments based on a pre-existing thesis about a category. That said, here are a few of the things we’ve been observing or thinking about. The list is nothing more than some of the things they find interesting.
> The list is nothing more than some of the things they find interesting. If that is true, I don't see the point of the article or that it warrants much discussion. I don't think that is the intent of the article though. I took it as they expect these 16 themes to yield a lot of the new ideas they will invest in. If that is the case then these 16 are quite arbitrary and I don't see why these were chosen.
Re: 16 Things
#124Re: 16 Things
#125Earlier quoted context omitted.
What bothers me are things like this which appear to be marketing messages aimed at CYA types or to simply lather up grandpa and the media: "The threat of people getting into our systems today is so great that every company in the world has to embrace the notion that not only are they going to get hacked, there’s a good chance hackers are already inside … and they just don’t know it." ...and this: "This set of compan…
Well, customer data isn't stolen by actual hacking, in my experience it's humans. So many companies, particularly younger ones, have zero interest in putting up barriers to access as the company grows because in the early days, everybody was trustworthy and "because bureaucracy bad". So all the customer emails, phones, addresses, birth dates (and, I'm guessing, in the US SSNs) routinely fly around in Excel files call…
Re: 16 Things
#126Earlier quoted context omitted.
Subscriptions make sense with Podcasts. It's kind of like a season pass for a TV show on iTunes. They tend to be something you follow and want each episode of rather than something you listen to once. I think this is mainly because finding something you like is difficult (good content, good hosts, good length, good production values) so you stick with it when you find it.
That's not how Hulu, Netflix and Amazon handle it. The subscribe thing is unnecessary.
Re: 16 Things
#127For instance, the cost of an endpoint CPU and memory is a 1000x cheaper than the cost of CPU and memory in the server. [1] What do they mean? How was that calculated? It sounds completely wrong. [1] http://a16z.com/2015/01/22/cloud-client-computing/
I think this "thing" is insane. First of all, battery life. He specifically calls out phones, and "not just phones, they could be wearables and other...", as targets for this. Every bit of computing you do on my device is battery life I lose. You're welcome-in-theory to use some compute on my CPU, but stay the hell away from my battery life, which in practice means stay off my CPU. So there's that. Second, latency is…
A) Whenever data volume is large and it would take forever to shove it up to some server.
B) Whenever offline service availability is crucial (i.e. you don't want to be dependent on network service availability)
C) Whenever you want to be in control over where your data ends up.
For example Computer Vision is an instance where these criteria are usually met.
Re: 16 Things
#128For instance, the cost of an endpoint CPU and memory is a 1000x cheaper than the cost of CPU and memory in the server. [1] What do they mean? How was that calculated? It sounds completely wrong. [1] http://a16z.com/2015/01/22/cloud-client-computing/
I think this "thing" is insane. First of all, battery life. He specifically calls out phones, and "not just phones, they could be wearables and other...", as targets for this. Every bit of computing you do on my device is battery life I lose. You're welcome-in-theory to use some compute on my CPU, but stay the hell away from my battery life, which in practice means stay off my CPU. So there's that. Second, latency is…
I think this _is_ actually worth trying out (albeit as an experiment). If you can send JSON to the client (and have already cached the templates) rather than full rendered (uncacheable) HTML, you can (hopefully) reduce the amount of data that's being transmitted. This saves you in
* latency - downloading a small JSON file will take less time than downloading a large HTML file (although with 4G and later high-bandwidth mobile data this becomes less relevant) - at what point does the additional download time offset the template-rendering CPU time?
* CPU usage (and hence battery life) - if we assume HTTPS for the download, the TLS decryption isn't free - at what point does it use less CPU to render your JSON client-side than to download a big file?
* radio usage (and hence battery life) - downloading more content means your radio must be on for longer, which is likely to use more power - at what point does the additional radio usage offset the CPU usage?
In each case, I don't know where the balance lies, but I don't think it's clear cut that server-side HTML rendering is always a better thing on mobile devices.
Having said that, I definitely agree with you on the battery life for general computation point - I'm not going to be bitcoin-mining on my cellphone! ;)
Re: 16 Things
#129Re: 16 Things
#130Earlier quoted context omitted.
Well, customer data isn't stolen by actual hacking, in my experience it's humans. So many companies, particularly younger ones, have zero interest in putting up barriers to access as the company grows because in the early days, everybody was trustworthy and "because bureaucracy bad". So all the customer emails, phones, addresses, birth dates (and, I'm guessing, in the US SSNs) routinely fly around in Excel files call…
So genuine question: How should one manage their marketing intern so data doesn't leak?
Next best thing is to sanitize your data; hash any personal information like emails or phones, take a day or two to build a rudimentary BI database that has sanitized information on it before giving people access, use work emails to manage access to everything and log it (my team built https://github.com/zalora/sproxy for this purpose), silo access, teach people SQL, and so on.
But honestly, to most management teams security is dead last on the list of priorities; it's just another tail risk that probably won't happen, if it happens it doesn't matter that much, doesn't cost that much, and there are a thousand other things on their mind like growing the company which are more important ('compliance is for when we'll be profitable' or 'we're not a bank, it's ok'). You can't do very much when working in such a company.