scootklein

Side project to easily unsubscribe from marketing lists. Just forward the email to the unsubscribe address. No inbox access required.

https://captainzero.ai

great team and problem hits really close to home. congrats to them!

StatusPage.io | San Francisco or Denver | Full Time | ONSITE

Hiring developer and technical operations leads. Senior level to help us build an incredible infrastructure and development team.

https://jobs.lever.co/statuspageio/

StatusPage (YC S13) | San Francisco or Denver | Full-time | ONSITE

StatusPage is building a transparency layer for the internet. Our current product exists as hosted status pages for public facing SaaS companies and groups internal to companies (private status pages)

We're bootstrapped, profitable, and looking to grow the team with people that like learning from each other and take pride in their work.

Current positions: - Development Lead - Operations Lead (DevOps in flavor) - Lead Designer

https://www.statuspage.io/careers | hi@statuspage.io

The risk profile as you seem to be thinking of it is an irrelevant metric when you're only interested in the return profile. They're optimizing for dollars returned, not % of companies sold for greater than money put in.

Consider a "soft landing" (VC gets their money back), vs complete death (VC gets no money back). When put alongside a $3B acquisition they're both completely irrelevant, even if on paper the 1x money back is not considered a "failure".

Check size doesn't appear to matter, the data for YC and for VC that I've seen suggests a similar power-law-ish distribution of returns.

Just looking at YCs returns, the vast majority of the wealth appears to be concentrated into 3 of 600+ starts (Dropbox, AirBnB, and Stripe). Even a Heroku sale for 200M+ is a drop in the bucket compared to $10B private market valuation, say it out loud and it will sound weird. "Dropbox is worth 50 Herokus"

Betting the farm implies that they have no other options, which is not the case with VCs, and it's impossible to know which will be their "super unicorns" when they write the checks, so they write lots of checks.

There's not much reason to believe YC is unlike other angel groups, individuals, or VC firms, and their data should back up that the majority of their returns is 1 or 2 companies every so often with huge wins.

once they're already a customer you're correct. the OP did mention the other major factor of a status page - a sales tool. prospective customers want to see incident history, who was affected, their response modes, metrics like uptime and latency are always good, etc.

Founder of statuspage.io here.

This is 100% a tool problem, and a problem we're actively working on for customers of ours that plan on having thousands of customized "views" for what they normally consider a "status page". Per-user functionality is one use case, but it can and will go deeper than that. If they could post an incident such that only you can see it, or such that only you are notified, they most certainly would.

I disagree that posting everything to be globally viewable is the right course of action, as this outage doesn't necessarily implicate fault on DO as a provider, but it also doesn't mean that you as an individual customer shouldn't have access to your specific view of a status page as it relates to exactly what infrastructure you live on.

You'd be surprised how prevalent this issue is, and how much inaction it creates on the provider end.

your first characterization seems incorrect (did you read the story? it wasn't application errors), and your second characterization is hyperbolic at best. calling it a high-level constraint doesn't mean it's common, nor obvious.

calling them "terrible practices" is redundant, all devops horror stories can be characterized as exposing terrible practices if you're simply looking at the post-hoc view. it's a feature, not a bug, to make light of them. they're laughed about, but with the intent that they're not made again.

anecdotally, probably half and half. even personal connections can be slow and are super busy :). the other 10 were cold signups that surprised us, but enjoyed what we were doing.

This is a great writeup. Any time we can bring subconscious "gut feel" into the conscious is a win for everyone, and uncovering these kernels of truth has got to be enjoyable from a CEO standpoint.

Are you asking about us having an outage on our site, or you having an outage on your site? If the latter, you could definitely set up a redirect like the mentioned article to forward all of your traffic to your status page. We'll be doing a similar integration with Heroku for their maintenance and error pages.

StatusPage.io - just accepted into YC S13

Looking for tech generalist co-founder, more on the back end and ops side of the business.

founders@statuspage.io for more info

Care to comment on your experience with larger code bases? The content of your post seems short-sighted, and there's an exponential function of complexity increase as LOC and developer headcount both go up.

You're right people pay for features, but lagging a little at the beginning to establish good TDD culture pays off in spades later on. Shipping product is something you have to do continuously, and you arguably create more value as time goes on, so ensuring you can continue to ship product in a timely manner is a great thing for organizations.

This doesn't solve any of the issues associated with PCI compliance.

Namely - you still have the liability, you still have the maintenance and upkeep of the system, you still have to pay for certification

The only thing it takes away from you is building the system which, on time and materials basis, is not even close to the real cost of maintaining a PCI compliant system.

on the contrary, i've had a coffee shop owner tell me to come and stay as long as i want for one simple reason. more people at a coffee shop is validation for the passers-by that have no context for the value of said coffee shop. lot of people being there is the only data point they'll get.

I believe the author just has a technical misunderstanding of the way APNS works. In no ways is APNS aware of accounts logged in or logged out of a service - all of this happens on the app developer's server backend. The author's case is properly laid out, but the fault is of the app developer rather than APNS. Developers should take note - this is indeed a valid race condition.

APNS is simply an exchange between a remote service (ex. Twitter) and an application that has registered for remote notifications (ex. Twitter app). APNS knows nothing more than the key that it provided to Twitter to identify this device in a remote push context.

the tech is definitely geared in that direction. carpooling is first because we needed it for our own use :)

fair points for sure. obviously we're hoping the answer is "with this app, more people than normal".

This SOPA support was the straw that broke the camel's back.

Call this anecdotal if you will, but GoDaddy always occupied that "necessary evil" for domain registration in my brain. If others on HN are at all like me, they probably have > 75% of their registered domains sitting and doing nothing. GoDaddy's tasteless ads, horrible UX, shutdowns of domains due to "good faith" complaints...this was just the final incentive to call it quits. Predictably irrational, absolutely - guilty as charged.

Durham NC

ReverbNation

Job Title: Full-stack RoR developer

Looking for full-stack ruby on rails developers to join our main office in Durham, North Carolina. Job responsibilities include work on our main web property (http://www.reverbnation.com) as well as looking into mobile web technologies (html5, css, js) and bridge technologies for native mobile apps (PhoneGap). Development organization currently has 12 members, up from 6 just 11 months ago.

Company is doing really well financially, 43 staff members up from 20 just 11 months ago. Definitely long on money and short on resources at this point.

Contact info is in my profile.

what spotify has over its competitors is distribution through facebook [1]. this single factor makes the rest of their competitors numbers (and quite frankly their own numbers) more or less irrelevant. keep in mind, too, that it says "users" and not "paid subscribers"

[1] http://blogs.forbes.com/parmyolson/2011/05/25/facebook-to-la...

if you're going to comment on the quality of participants, i would suggest you refrain from using words such as "idiots"

"Failures are the stepping stones to success. Without failure, we’ll never learn how to succeed. So try to fail, instead of trying to avoid failure through fear."

I don't know how this one has hung around for so long (seems like a cultural cornerstone of valiance), but I find it just plain wrong. The first part of it (stepping stones) is reasonable, but the second part is doing a great disservice for those struggling every day to try and achieve their form of success.

Suggesting and encouraging failure is not the same as embracing and supporting it when it happens, and the author seems to be conflating the two.

This title is misleading. Sure, there are development quips here and there, but I don't think it's more than any other language/platform. "Apple puts usability first" would be more appropriate.

Recent news and dissent from developers has been largely around political moves and gestapo tactics to keep its property exactly as it wants it. Consider a number of issues in which it isn't putting its users first

* taking 30% of all subscription fees, effectively a pass-through tax or killer-of-app in some cases (think Pandora)

* not allowing you to pay for digital forms of physical manifestations with in-app purchases (think concert tickets)

* not allowing you to run unauthorized apps even if you sign your life away that you know the risks

What's most sad about the loss of potential is that we never know what we're missing out on because it's too much of a business risk. There are many companies that are still looking at the App store with trepidation - beautiful, useful, life-changing things are inevitably lost (won't come to market through the App Store) and nobody will ever know what they "could" have had. That, in my opinion, is the saddest of all the injustices.

couldn't agree more. i started with java in high school and was too caught up in "public static void main" to realize that it was up to me to define methods that made sense and that things generally ran top to bottom. switching to php for a while made everything "click" before heading back to java

getting rid of CS terms and data types allows you to learn how to think in program flow and "what am i actually doing here". failing to capture the attention in this first step is lethal to most people that otherwise would be good at programming if they hadn't run quickly at their first try

You submit this as if mandatory truency laws will help them change between the ages of 12 and 25. The parent comment was making the point that if we're looking at a child whose parents and peer group don't care then they shouldn't be allowed to negatively affect the rest of the classroom.

With parental involvement and peer group being such an enormous pressure on kids, taking away 1 of the 2 toxic influencers can do wonders for the other 75-85% of the kids.

A traditional economist's view of behavior would answer "yes" to this question even if that isn't always the reality. You hit on the point though - not going back to school could very well be the best thing for you. You won't know until you try, and the opportunity cost of time is rarely factored into that equation.

It's South Dakota. I may have been hyperbolic about the hefty margin, but the 100 mile statement I would go to the mat for.

I'm even convinced that updates are processed programatically in many cases, and that a human doesn't even see it if it marches certain criteria.

We ran a website that let users create their own iPhone apps so bugfixes to the platform required 55+ apps to be rebuilt and resubmitted at the same time. Emails for all 55 apps would come in at the same time every time they changed state (30 or so seconds to receive all 55) and was very consistent through all of our updates.

FWIW, some more anecdotal evidence

1) after the switch to 4.0, updates to my apps that added background audio and support for the high res screen were through in 2 days. during this same period, normal bug fixes took around 12 calendar days

2) just updating images and names can take upwards of 3 weeks for non-popular apps (you think it'd be the opposite)