velominati

This article states that former employees are "lining their pockets" at the expense of current employees who are "build[ing] future shareholder value" (i.e. creating value for VCs). But it ignores the fact that those former employees already built shareholder value when they were working. And by joining early on they took a much larger risk than employees who sign on during the growth stage - often receiving less salary and certainly holding more uncertainty over the future value of their equity.

A longer exercise window is a benefit that accrues to all employees, because it applies to all of them.

The author's proposed solution feels quite absurd to me - to prevent exercise of stock options by any employee who departs for a liquidity event. I wouldn't join a startup that had these provisions.

Some interesting numbers:

  * The US Population is 320 million [http://www.indexmundi.com/united_states/demographics_profile.html].   
  * Our federal budget is $3.9 trillion [https://en.wikipedia.org/wiki/United_States_federal_budget#Total_outlays_in_recent_budget_submissions].   * If every dollar of the budget went towards BI (no defense spending, no infrastructure, etc), that would be $12,260 / person / year. 
  * If you limit it to adults, it ends up around $15,000 / person / year (about 80% of the US population is 15 years or older [http://www.indexmundi.com/united_states/demographics_profile.html]).

This actually lines up pretty closely to the official poverty rate [https://en.wikipedia.org/wiki/Poverty_in_the_United_States#R...]. It equals an hourly wage of about $6 / hour.

I wonder if there were a BI, if those at or near the poverty line would tend to get more efficient with their spending. For example, moving towards lower cost parts of the country.

It's great to see a lot of the good DNA from the Heroku Postgres team reflected in this release. Congrats on the launch.

The UX of this app is quite innovative and immersive.

You are applying heuristics that are true for man websites, but don't apply here. I would say this is more like a simple video game. It would make no sense for example to have navigation control over this video. That is the point, you can't just rewind to before the accident occurred.

There are two separate issues here. Requiring arbitration is one. Disallowing class action is another. You cannot conflate these two things.

Disallowing class action is absolutely in-favor of Slack and companies in general. Class action suits are a powerful pro-consumer force. They allow consumers to seek redress without cost - as the legal costs are paid for by the plaintiffs attorneys. Sometime consumers don't get much out of these suits while the attorneys make a lot. But their threat is a strong check on powerful companies.

Forcing arbitration is a murkier matter. The first google result on arbitration vs trial (http://www.nolo.com/legal-encyclopedia/arbitration-pros-cons...) provides a decent analysis. Frequently arbitration is less expensive for both sides because the process is simplified. You also avoid shenanigans like fighting for 6 months about jurisdiction and venue (which either side can do to seek a more favorable court).

The article states that arbitration is bad because consumers don't have legal representation. This is flat out wrong. Consumers can and should have legal representation in an arbitration. Just like in a trial, consumers need to pay for this legal representation themselves, and it would be foolish not to have it.

The article also says that arbitration is bad because companies have more legal resources than consumers. This is a fallacious argument. Companies will also have more legal resources in a trial. If anything, the simplified process of arbitration makes this less of an advantage. So arbitration may be slightly better for consumers in that respect.

The blog post says that PX dynos are currently c1.xlarge (see https://blog.heroku.com/archives/2014/2/3/heroku-xl#performa..., paragraph 4).

This hackathon is part of Dreamforce (http://www.salesforce.com/dreamforce/DF13/), Salesforce's big annual user / partner conference. Dreamforce normally costs $1199 to attend, but that was way to big of a cost barrier for a hackathon, so they created a $99 pass that doesn't include sessions or the concert, but does provide access to the developer area (all of Moscone West) and keynotes (Sheryl Sandberg is a headliner).

I'd ask yourself not if $99 is worth it for the hackathon, but if it is worth it to attend Dreamforce as a developer. I have found it to be a useful view into the world of enterprise software-as-a-service, both in what solutions are and are not available, but also in the way they are marketed to businesses. You might even get an idea for your next startup...

And if $99 is too expensive, there is also a free pass that provides access to the keynotes and expo floor only. But not the developer area where the hackathon is located.

Full disclosure: I work for Heroku, a Salesforce company

I'm a PM at Heroku. The dyno redundancy check has nothing to do with protecting the platform. It is a best practice for production apps to have redundancy at the web server level. This protects your app from downtime should underlying servers fail, or if the web server process were to crash. N+1 redundancy for the win.

Also, it does not cost customers double because the first dyno is free with each app.

That's not right. In any configuration the goal is to minimize queue time. What is critical to doing this is having a request queue and a pool of concurrent "workers" (to use the generic queueing theory term) in back of it.

Unicorn uses the operating system's TCP connection queue to queue incoming requests that it is not able to immediately server. While n+1 requests can (and will) get routed to a single dyno, this only results in 1 request being queued. It will be queued until the first of the in-process requests is served, which will take ~ the average response time for the app. Given that the other n requests did not get queued (queue time = 0), the average queue time will equal Sum(queue times) / # requests = Average Response Time / n+1.

Some public companies (mine included) have specific guidelines around how information is disseminated that can be reasonably be expected to impact share prices. If you look at the NASDAQ website (http://www.nasdaqtrader.com/Trader.aspx?id=MarketWatch) they have their own regulations about how it is handled. I'd imagine there are SEC regulations around it as well.

brew was a big step forward. But 1 step (download postgres.app) is better than 3 (install devtools, install brew, brew install postgres).

We saw that many developers were using SQLite (or MySQL) on their local machines, but Postgres on Heroku. This led to frustrating and hard to diagnose bugs and behaviors in their apps. Our hypothesis is that easier local install will lead to more widespread usage for the technology.

Postgres.app was in beta until today. Now it is GA. This was our first public announcement.

Don't reserve for 3 years.

AWS cuts their costs at a relatively reliable rate. We've done the match an found that the 1 year reservations are absolutely worth while, but that the 3 year reservations are not. Granted that was for our specific workload / use case.

Money has a time value, and this stuff is getting cheaper fast.

We've generally found that this sort abuse rarely happens. Generally developers utilize our services as they are intended. And it is much easier to release new services and watch for abuse than to pro-actively restrict them before-hand.

There is nothing wrong with storing blobs in the database - it is one of the data types. But a database is not a replacement for AWS S3 either.

If we did find someone abusively using the database - especially if it was affecting the overall quality of service - we would reach out to them directly to address it.

That's right. They are all Japanese things in increasing order of deadliness.

Thanks for the feature request. Attaching multiple apps to one DB is something we've wanted to do for quite a while...

FYI, you can hack this by provisioning a database on one app, then manually setting the DATABASE_URL config var on a second app to match that of the first app.

Keep in mind that the dev databases have Continuous Protection (https://postgres.heroku.com/#protect), and manual backup plans work on them as well.

We haven't determined the limit yet. Our goal is that it is more than enough to evaluate the heroku platform and to develop and test on, and high enough that any of the existing shared:5mb databases can migrate to it without worries.

It will very likely be on the order of 10^3.

We will certainly have a deprecation / transition period between the existing shared db plan and the new development plan that will give users ample opportunity to migrate their data. Safely preserving data is our number one priority, so this will be handled carefully.

The shared 20gb plan (based on the older, Postgres 8.3-based architecture) is still available, as is the free 5mb shared offering. We won't replace these until this new development plan is out of beta. Once we do we will continue to have a database plan at or near this price point. Stay tuned.

Matt Soldo (Product Manager, Heroku Postgres)

Doing joins or foreign keys is no problem. You simply join against the appropriate hstore function.

Yes... why would any website that values privacy and security not use HTTPS for everything? We've been doing that from day one on https://postgres.heroku.com.

Pure spin: Pinkus is trying to make this story about merit and reward. But really its about not honoring contracts.

The stock options given to employees were part of their employment contract with the firm. They were based on imperfect knowledge of future facts on both parties, i.e. taking risks. Zynga attempted to use its power to revise the contract post-hoc.

If I have to negotiate a deal of any sort with Zynga in the future, I'll be wary of them honoring it.

Sure, if nothing has changed in the product, the press doesn't want to write about it, the news is about whats changed in the world.

But what the press does like is hearing about how existing products have made businesses successful. These stories are about the success of the business as a result of the product, which is the thing that is changing for companies with more static products that are very successful.

The startup has committed what is known legally as "Promissory estoppel", basically a broken promise. In general they are liable for any reasonable expenses that you have incurred with the assumption that they would keep the promise. If for example you had already moved to the bay area, you could file a lawsuit to recover the cost of the move and the cost of moving back.

If you do want to get any monetary compensation from the company, I would suggest bypassing the recruiter and speaking with a founder or executive at the company directly. Hopefully they will be motivated to do the "right thing", and they will certainly have an interest in preserving their reputation.

DHH makes a few mistakes in his reasoning here. I have an MBA and work for a successful YC startup. Here are the flaws with his argument:

1. Mediocre business schools aren't worthwhile. And although school rankings are only an approximate quality measure, any school that isn't in the top 30 in the world or top 10 in the US is probably mediocre. He is basing his analysis on his experience at the University of Copenhagen, which doesn't make most global rankings (http://rankings.ft.com/businessschoolrankings/global-mba-ran..., http://online.wsj.com/public/resources/documents/MB_07_Score..., http://www.businessweek.com/bschools/rankings/), doesn't crack the top 30 in Europe (http://rankings.ft.com/businessschoolrankings/european-busin...), and doesn't actually offer an MBA (http://uk.cbs.dk/degree_programmes). In addition, the 3 year program the DHH refers to is actually an undergraduate program (the MBA is a graduate degree).

2. Internet businesses operate at large scale (if they are successful), and understanding large scale businesses operations requires quantitative analysis. Working for a YC startup myself, I can attest that what I learned in business school is incredibly useful. My school (Wharton), focused on quantitative analysis, and I came out of it with a set of tools that I use everyday. These include statistical analysis, quantitative model building, quant marketing tools, and financial analysis. Of course you can learn these tools on your own, but you risk not knowing what tools are available to address the problems you face.

3. In addition to tools, a good MBA program will teach a general problem solving technique to systematically break down, analyze, and solve business problems. And it will teach you to effectively communicate your solutions to others (you boss, a client, a VC, whoever). Some people are naturally good at this and don't need an MBA to do it. But many need to be taught how to think in this manner.

4. As another commenter pointed out, a lot of value from getting an MBA comes from networking. However if you get an MBA in one country (Denmark) and then move to another continent, that network will be less useful.

5. Many of DHH's lessons about building a successful startup - including charging for your product, picking a competitor, and rejecting conventional thinking about starting a tech company - are exactly the type of things you learn while getting an MBA. In fact, rather than learn specific lessons like these, you learn a framework for evaluating your business and market, and formulating the right way to structure your company.

DHH does make a few good points, both explicit and implied:

1. Strategy frameworks like the Porter's 5 Forces (he incorrectly describes it as a management theory) aren't particularly useful for starting companies. Although these frameworks can help to gut check if a startup is entering a good or bad market, they won't be at all useful in the day-to-day running of a company.

2. Based on my small sample set (of 1 school), I don't think business school is useful for learning how to build a product or be entrepreneurial. Granted, some schools specialize in this and mine did not, so other schools may be useful in this regard (Stanford GSB is known for entrepreneurship).