johns

Breaker for iOS does a good job of recommending episodes and podcasts based on your likes and friends. I recommend it.

This is the reporting interface I wish our product had. I tried out Sigma during the beta and was very impressed with it, especially the front-end. SQL is a bold choice but I think the right interface given the structure of Stripe data.

It's based on Electron

You'll also end up cloning their mistakes, except that they know what didn't work out and you won't for a while.

Can anyone clarify the when or why you would use this instead of or with Athena?

There are a lot of people.

No

I wonder if Stripe is going to do one again this year: https://stripe.com/blog/open-source-retreat-2016

Another endorsement for HelpScout. Web app is great. iOS lacks features in a way that drives me crazy every day (team is well aware of them) but I still think it's the best available with fair pricing.

I hate the pods, but they have a recycling program. Unlike K-cups.

In defense of Hackbright, I have hired multiple grads from there and had we had the room, hired more great candidates we talked to and all were great. Consistently produced good candidates. Just like any class though, there's going to be a distribution in results.

Author here. It's been awhile since I wrote this and we've learned a ton more about what good API monitoring looks like. So if you have any questions, let me know!

Hey maybe tone it down with the sock puppet accounts.

Dupe: https://news.ycombinator.com/item?id=13428595

I hope using a tweetstorm to announce his departure was a subtle shot at the company's inability to ship a product the way people want to use it.

You should expand to recreational sports teams. The logos all follow similar formats and everyone wants one that looks professional but on a limited budget. There are design services that will do it manually but your algorithm approach would work really well for it as well.

Or dragging them

I did a talk a little while back on providing a good developer experience around webhooks that covers a lot of the same topics. I wish I had a recording of it, but the slides are here: https://speakerdeck.com/johnsheehan/crafting-a-great-webhook...

Edit: found the video https://www.youtube.com/watch?v=xc5ezyJjz1k&feature=youtu.be...

When I was at IFTTT (a few years ago, so it's definitely changed since then) we tried not to rely on the content of the webhooks and just used them as a hint as you describe to fetch new data. Not every API made this easy though.

If receiving a webhook is critical, you should make your receiver do as little as possible to place the event into a resilient queueing system and then process them separately. That won't save you from bad DNS, TLS, etc. configs but it should help reduce the possibility that you DoS yourself with a flood of webhook events.

Also (shameless plug), you could monitor and log them (we offer retries if your server fails): https://www.runscope.com/product/alerts

https://www.runscope.com/docs/request-capture paired with https://www.runscope.com/docs/api/messages can do that.

Or use http://blog.runscope.com/posts/monitor-your-webhook-workflow...

Thanks Patrick :)

It will start dipping below freezing sometime this month and start warming up enough for outdoor activities again late March/early April.

Different kinds of people work at BigCos and startups. Some overlap and occasionally you compete but not always.

For your situation: go work in SV for a startup. That will get you in the circles and connected. Australia is easy to hire from for US companies because of E-3 visas.

Here's a sample app: https://github.com/zeit/nextgram

Try not using 'guy' when you mean 'person'

Runscope | Remote (US or UK) | Technical Support Lead

We are a small, profitable company working on API Performance Management tools used by over 75,000 developers. We're recently off the VC train and are operating profitably on our own income. We're in need of someone to answer questions from customers which are primarily technical in nature. Majority of time will be spent answering tickets via email and live chat. We use HelpScout and Intercom mostly. A desire to contribute to our public documentation, knowledge base, and blog are a bonus. Must be highly self-directed, organized and a clear communicator.

If you like APIs and helping companies save millions of dollars preventing downtime, we'd love to talk: john@runscope.com

Interview process is meeting with each founder via Skype for about 2-4 hours total. We will also send you 3 sample support requests to answer after the initial calls.

We were also built from the ground up with microservices and had the exact opposite experience. Faster shipping (more value to end users), more predictability (APIs designed/behaved similarly across functions despite polyglot tech), much less coordination overhead (deployed dozens of times per day with a < 10 dev team, pre-release backends well in advance of the user-facing parts), etc. We had to invest a lot in infrastructure, but that was worth it for many other reasons as well. Dozens of repos is annoying, but not for a technical reason (a lot of SaaS like Bugsnag and GitHub used to charge by project).

The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the software are so inextricably linked that it is not portable in the least bit.