goronbjorn

Probably just placeholder. Usually they'll link to the videos of the talks the speakers gave that day.

As with all acquisitions, if they give them a healthy amount of autonomy and give them more resources than they would've had as a startup, then I can see this going pretty well. Huge and improbable "if", but it's worth pointing out.

Hm, I guess I meant more in terms of their involvement with the event at large. As far back as 2007 (http://web.archive.org/web/20070105191044/http://startupscho...), Startup School was run by YC along with BASES.

My only guess would be since they don't need a venue on Stanford's campus, they don't need help from BASES anymore, but I was just looking for someone to confirm.

What happened to BASES?

They probably left out pandas because it depends on numpy and also this point:

> For many people, installing numpy may be difficult or impossible.

that's as true, and arguably more, for pandas.

How does this compare to Macaw: http://macaw.co/

The font in this post isn't legible at all.

"Good artists borrow. Great artists steal."

What are some examples of party rounds?

That's true, though even 10% of that number (more than twice the out-of-pocket cost with insurance) would've been financially crippling.

When I was in college, I couldn't afford health insurance (no parents + financial aid does not cover it). I played rugby (generally not the safest sport) for two years, in addition to playing pickup basketball all four years. I very fortunately did not sustain any major injuries.

Six months after graduating (and getting a job with health insurance), I tore my ACL while playing pickup basketball. The costs were as insane as outlined in this post, but, again, I had health insurance. However, to this day, I'm horrified at the thought of what would've happened if I'd sustained the injury in college when I didn't have health insurance. Shame on me for putting myself in those sorts of situations, but it feels like there's something wrong when the penalty is so harsh.

Plinko!

(http://en.wikipedia.org/wiki/List_of_The_Price_Is_Right_pric...)

If anything, this post shows that Medium needs a good way to display code snippets–having to resort to screenshots is pretty gross.

Photos on Snapchat vs. Photos on Facebook/instagram is an apples to oranges comparison.

Snapchat is a messaging platform, so it would make more sense to put in context with other messaging platforms, like Whatsapp, iMessage, etc.

BitTorrent has orders of magnitude more potential for the enterprise use case than for the consumer use case.

Yep, for more evidence on how little oversight contributors are given: http://www.forbes.com/sites/jonmatonis/2013/05/27/donations/

I was in the crowd for this talk as a student. Three months later, I interviewed at Box. Haven't looked back since.

I would argue that, in this case, long term irrelevance is a "major threat" to Yahoo!'s existence, and this is one of few ways to circumvent that. There's going to be the same seemingly irrational price pinned on this acquisition because it's a long term life or death situation.

> In the end Tumblr won’t see a bigger exit because they didn’t prove they could monetize their massive traffic before time (and money) ran out.

Instagram had $0 in revenue when they were acquired for $1 billion in cash/stock. The price paid in that instance was for potential, and it's likely to be the same in the case of Tumblr.

This is kind of like Stypi, except with REPL, cool!

This is going to sound like I'm trolling you, but pdf.js only supports PDFs. You'll need to convert those other doc types to PDFs before using them with pdf.js.

Wow this is great! I was literally working on something just like this last week.

A couple of things I found to be of value in my project that you might find helpful:

1) Endpoint-level granularity

A lof of APIs are RESTful these days, and the trend is for more to be that way than not. It would be nice to see (optionally) the uptime broken out by resource for that API. APIs generally connect to a bunch of different backend services on the API provider's side (think the difference between SMS and Voice with Twilio), and there's a high likelihood that one part could be down while the other is not (e.g. SMS is down for Twilio, but Voice is not).

2) Response Times

This is tricky because response times can be fickle for any number of reasons like network issues, for example. However, I've found that there is value in monitoring response times and big jumps (e.g. anything 1-2 standard deviations off the norm warrants an alert). What would be really cool is if you can monitor response times across various AWS regions.

If they stay committed to it, it will get a lot better over time, both in terms of functionality and form factor. That's a huge if though.

They're in talks with Warby Parker about making more stylish models.

Totally agree. It wouldn't be too hard for someone to build a lightweight frontend to their API with a d3/raphael charting capability.

Love using Trello at work, and this makes it even better.

My one gripe (that many people have) is the lack of built-in metrics/analytics on progress. You can hack it together with a combination of the Trello Scrum extension and their API, but it would be great to have it built-in (and something I would pay for).

The question people keep asking: 'What does this change about whether or not developers will use Parse?'.

Before being acquired by Facebook, there was a non-trivial probability that Parse would not be around for the long run. Being backed by a large company that isn't going away anytime soon makes Parse a viable option for larger businesses that are more risk averse than smaller startups/developer shops. Early adopters are great for shaping a product, but the majority of the money is in those risk averse enterprises. In other words, being acquired by Facebook hops Parse to the other side of the chasm [1]. There was a similar effect with Heroku being acquired by Salesforce.

I'm not sure what the long term effects of being associated with Facebook's brand are going to be, but there generally is a lot of short term vitriol associated with anything Facebook does that eventually ends up being inconsequential; if I were Parse, I wouldn't be too concerned, especially when their actual numbers indicate developers haven't lost faith in them.

[1] http://en.wikipedia.org/wiki/Crossing_the_Chasm

I've tried Strikingly and really like it. I would like to recommend it to all of my non-technical friends who want to make simple websites but can't afford to hire someone to do it, instead opting to use things like iWeb (yes, average people actually use iWeb).

However. I'm apprehensive about doing so because I'm worried about Strikingly being acquired, and my non-technical friends being hung out to dry with their websites. These days it seems like any startup pre-Series B that gains traction is liable to get acquired and possibly disappear. I wouldn't want to put my non-technical friends in a situation where they have to deal with that.

This seems ideal for the enterprise use case, in particular because it's extremely performant, secure, and doesn't require a central/third-party server (e.g. AWS). The 'must always be online' requirement is actually a plus, not a minus for that crowd. Enterprises are generally very concerned about being able to revoke access to a given resource instantaneously. Any app that stores local copies complicates that quite a bit.

People will dismiss this as 'a toy that geeks use', but as Chris Dixon has noted, 'what the smartest people do on the weekend is what everyone else will do during the week in ten years' [1]

[1] http://cdixon.org/2013/03/02/what-the-smartest-people-do-on-...

When a company does something like this, whether or not the claims/criticisms are actually true, their actions tacitly imply that they believe that the claims are true. In other words, terrible PR/technical brand management.