estreeper

I've really enjoyed looking at the GraphQL JavaScript reference implementation source [1]. It is well-commented, consistently formatted and structured, and makes frequent references to the spec. The spec itself [2] is very well written too, and I think the project being spec-driven along with the code quality make it a good example.

It feels like a lot of thought was put in to making the code well-documented and easy to follow for people new to the project.

[1] https://github.com/graphql/graphql-js [2] https://facebook.github.io/graphql/

In finance theory, as long as a company is able to grow at a rate higher than the rate at which you could reinvest your dividends, you prefer not to receive a dividend. More simply, the idea is that the money staying in the company will grow more quickly than if it's outside of the company so long as the company is doing well.

Like a lot of financial theory, I think this is partly true. However, in my view, one of the side benefits of companies giving dividends is that it acts as a sort of long-term "anchor" to the stock's instrinsic value: the amount the company's stock is actually worth, which is usually wildly different from what it's worth on the stock market.

Let's say through careful analysis I find a company I think to be greatly undervalued in the stock market. I buy a bunch of shares. If they don't pay a dividend, I'm just hoping that eventually the market will "notice" the discrepancy and the price will go up, but I bear a lot of risk because the opposite could happen. But, if that company pays dividends, and those dividends continue to grow, I am getting a real return which is not based on the vagaries of the market.

As a practical matter, voting rights are, by and large, pretty worthless. Even famous activist investors with very deep pockets (Carl Icahn, for instance) are usually limited to causing just enough trouble to get management to make some "go away" changes. Plus, management works hard to put in place measures to entrench themselves: anti-takeover defenses, requiring super-majorities for certain changes (often mergers and buyouts), etc. A lot of these moves were undertaken by management of companies in the 1980s in response to a wave of so-called "hostile takeovers" in the 70s and 80s.

An interesting example is Alphabet/Google. Their class C shares (which have no votes) are trading at $691 right now. Class A shares (which have one vote) are trading at $705, which is 2% higher. That seems like a small difference, considering you're giving up any kind of voting rights. What if management starts to perform poorly?

Well, guess what? Insiders (and only insiders) have class B, which have 10 votes each, so you're not going to have much luck as an activist shareholder mounting a fight against that.

> Is there any reason to think that this market is a winner take all?

I personally doubt it. Exceedingly few markets are winner-take-all. Plus, monthly subscribers are "sticky", so they're not going to leave overnight if one competitor gains a slight edge, and everyone else will have a chance to catch up.

Your point about the labels and streaming services as middle men is a good one too. Labels own all the content, so they have a lot of power to influence the market as well.

This doesn't seem that surprising.

  2014 Revenue: $1.3 billion (up 45% from 2013)
  2014 Net Loss: $197 million (up from $68 million loss in 2013)

That's a lot of money to be bleeding and losses are increasing even as revenue grows. If you wondered why they got terms like this, that would explain it. You can call it getting "strategic resources" if you like, but I call it running out of cash.

http://www.nytimes.com/2015/05/09/business/media/as-spotify-...

Perhaps one strategy would be to give them a baseline salary (higher than your current salary, of course). You could tell them that in general based on the kind of work you are doing, responsibilities, etc. you would expect more, but under no circumstances would you consider any offer less than that.

> Big companies buy 'disrupters' when they fear their market share is at risk.

Yep. I can see why they don't wait for them to crumble though. What if they don't? That's a big risk to take.

When a potentially disruptive product gets bought, it virtually always means death of the product. You get fed a line about how it's going to keep going, and then a few months down the line, it has all been integrated into some existing big company product.

What's sad to think about is that sure, a lot of these companies would have failed, but how many would have succeeded? We'll never know. I don't blame founders: it's pretty hard to say no to a mountain of cash when your future is so uncertain. But deep down, I still wish more would take the gamble.

As someone who is about to embark on a similar route, that's interesting and exciting to hear. Was it both Android and iOS? If so, how much of the codebase/time was spent on shared code versus needing to write platform-specific portions?

I've seen the Facebook post about developing Ads Manager (though it glosses over some details), but it would be interesting to hear other people's experiences.

https://code.facebook.com/posts/1189117404435352/react-nativ...

I wouldn't be so quick to dismiss its applicability.

I imagine a large part of what SOF do is solve unforeseeable problems in the context of trying to accomplish some goal, and to be able to adapt quickly if the goal changes. This is pretty analogous to what a startup is faced with when trying to accomplish a goal, when you'll find that most of your team's initial ideas, as good as they seemed at the outset, were wrong, and you'll be trying to face problems and seize opportunities that you didn't even know you had. For both SOF and these teams, being able to adapt quickly to new information and circumstances, and to resolve the problems that come up which will destroy you, are critical.

I apply "startup" also in the sense of "startup-like" teams in large companies who are required to innovate rapidly.

That's a good point!

I guess more broadly, I was thinking about a scenario in which the lock device dies, and making the point that conventional devices aren't foolproof either. In this case, the fool being me, and the proof being locking my keys in the house.

So, any lock can fail, but I'm not really concerned as long as it has a reasonably low failure rate. We've tolerated conventional lock systems failing (via user error mostly) for a long time.

I can see value in internet access. The lock having internet access means I can be on vacation in Thailand and grant a friend access to my house to drop off the rent check I left on the counter. And later, I can make sure my friend didn't forget. Or, make sure my dog-sitter is showing up. I also can't think of a more convenient way to grant access and identify people off-hand.

As for the connection going out, there are solutions. Redundant cellular connections, maybe? And if you really can't get in, it's not the end of the world. We already have solutions for that: locksmiths. Might be expensive though, and end up destroying the device, or maybe your door.

The data security thing is really bad. Unfortunately, that's a much larger problem though, not really related just to IoT.

I was just listening to one of Douglas Crockford's talks which discussed the contributions Engelbart made to computer science. What really stuck with me was the sheer number of new concepts he showed in his demo, which, though made in 1968, would showcase features not seen for decades, and some of which are still not effectively in use. If you haven't seen it, it's well worth the hour and forty minutes.

I think this is also a good moment to reflect on how incredible it is to be involved in a science which is still so much in its infancy that seminal figures in its development are still alive and well. Let us not forget their contributions, and most importantly, not overlook the concepts that, if employed today, can advance us far beyond where we are now.

Douglas Engelbart's Mother of All Demos: https://www.youtube.com/watch?v=yJDv-zdhzMY

Doesn't it seem like this analysis is done completely incorrectly? You can't directly compare two indices together that are based on different magnitudes (cost of living vs. salary).

If average cost of living in absolute dollars is $30,000 and average salary is $100,000, living in San Francisco nets you ($100,000 * 1.36) - ($30,000 * 1.63) = $87,100. Living in Pueblo nets you ($100,000 * 0.76) - ($30,000 * 0.88) = $49,600.

I'm afraid this will spark an unnecessary mass-exodus to Pueblo.