avibryant

Do you have any links to your experiments and/or those of your colleagues?

See also https://geoblaze-gsoc.vercel.app and the underlying libraries it uses, which also do range queries on GeoTIFFs.

I'm super interested in this space, including in helping financially support some projects. I already emailed Ted about this, but would be happy to chat to anyone doing this stuff. My email's in my profile.

(Luckily this is niche enough I'm not worried about my inbox blowing up....)

Well, I guess it's a good thing that I was a manager and basically never issued any operational commands over chat.

This is great! If you're interested, I'd love to have you at a GIS/mapping-focused retreat I'm hosting at https://www.gradientretreat.com/ this summer. You can reach out privately at avi@avibryant.com.

How hard would it be to support the Teensy boards? I didn't see any mention of them one way or another in the website.

Interesting, anyone else seeing this? It's hosted on Netlify and is just static HTML&JS.

From what I can tell, Causal's models only run forwards, with no inference (ie, they can generate predictions from priors, but they can't update those priors from observations).

Is adding inference on the roadmap?

Yes, we are - Rainier is used in production, though so far it's a very small part of our overall ML efforts.

Huh. No, for the record, we'd never heard that acronym when we chose the name for Dabble DB.

Stripe | Seattle | Onsite

Search & Query Infrastructure Engineers

I'm helping build a new team for Stripe in a new Seattle engineering office. We're focused on building distributed, scalable infrastructure for user-facing search and reporting-related features of Stripe's product. This is an opportunity to work on new, high-impact projects in a small team, while supported by the scale of Stripe's overall engineering organization and business.

Apply here: https://stripe.com/jobs/positions/engineer-seattle This describes our interview process: https://stripe.com/jobs/engineering-onsite.pdf

Feel free to also ping me directly at avi@stripe.com.

(BTW, since recruiters probably read these threads, we are also hiring technical recruiters in Seattle: https://stripe.com/jobs/positions/technical-recruiter-seattl...)

That was awkwardly phrased, I guess. I live in the Gulf Islands in British Columbia.

We're open to remote or distributed teams within the US and Canada. All else being equal, we'd prefer to hire people in SF, but for a sufficiently great team, being elsewhere wouldn't be a showstopper. We're conscious of not wanting to miss out on the diverse, talented set of people that happen to be outside of the bay area.

(I may be biased here: I work for Stripe from a small community off the Canadian coast).

I often cook steaks from frozen (sous-vide, or just low temp in the oven). I'm curious: is that one of the use cases you're testing or thinking about?

I take your point that there are a number of possible explanations (at varying levels of plausibility) for this effect, but to address a specific example you mention: whenever we change something significant in Checkout like adding the "remember me" option, we A/B test it, and if it did in fact cause a "horrible drop in conversions" we would absolutely not release it. (It doesn't).

That's a fair concern. The sample sizes here are relatively high: you can probably back some estimates out yourself from the numbers given in the post (millions of dollars raised, mean donation of $88, 14% of donations in the last week were repeat, etc). I'll also say that the comparisons in the post are significant to a 99% confidence level.

There are some nice, very efficient implementations of their solution #4at http://hdrhistogram.github.io/HdrHistogram/

Thanks very much for the feedback. (Feedback helps! As you may remember from the previous thread, we did change the Remember Me + phone number fields to be optional, in large part because of the feedback we got on HN.)

Each new payment method comes with its own constraints. We'll always try to give our users as many options as possible while working within those constraints. The constraints with Alipay are particularly tight, and for now the only way we can satisfy them is through checkout.js - but over time, if we can relax that, we will. We're definitely not moving to a model where Checkout is always the first or only way to integrate a new feature. For example, the two other alternative payment methods we have in beta right now are ACH and Bitcoin, neither of which are built into Checkout. We do hope to eventually support both of these in Checkout, of course, but in those cases, it was easiest to do the API first; in the Alipay case, it was by far the easiest thing to do Checkout first.

Sorry, I didn't actually answer your initial question: yes, Alipay is only available through a checkout.js integration, not a stripe.js integration. I think it's unlikely that we will do a stripe.js integration for Alipay - as Patrick mentioned above, it would probably have to be a redirect model like Alipay's other integrations.

However, it's possible that we could do a special alipay.js, which I think is what you're getting at with #2. This wouldn't be Stripe Checkout, exactly, but a standalone Alipay product where we provide the UI is certainly something we'd think about down the line. We don't have any specific plans here but feel free to email me at avi@stripe.com if you want to talk more about that.

(I work at Stripe)

Can you say more about "(a) stable"? If you mean that you've had problems with robustness or availability, I'd love to hear about that, because in general we believe it's been very good on those fronts.

If you mean that it the UI changes from time to time, then (for better or worse), that's a fundamental property of Checkout: we are continually iterating and optimizing and adding new features (like Alipay!). We do understand that it's not for everyone, but a lot of people use it for exactly that reason.

(I'm Canadian and work at Stripe)

How often do you actually buy things online with interac? I think I've maybe done it once, and the redirect-to-the-bank flow is pretty awkward. My sense is that this isn't ever a barrier to conversion for Canadians (except maybe for very large purchases?), but I'd be curious to hear otherwise.

I had the same thought, and went down the simplification rabbit-hole. Here's where I ended up: https://gist.github.com/avibryant/545e63b446a840951d5e

There was also a brief comment from pc about this a couple of weeks ago that might be worth linking to here: https://news.ycombinator.com/item?id=7400884

Yeah, for those same reasons I much prefer using Scalding's typed API [1], which feels very similar to Scoobi. The tuple API shown in these slides is great for places like Etsy that already have a large investment in Cascading, but otherwise you're better off getting the added type safety and similarity to the standard Scala API.

[1] https://github.com/twitter/scalding/wiki/Type-safe-api-refer...

(I worked on Dabble DB)

I don't think it's so much that there's no market for it as that the market is very hard to reach and we had no good channel. Intuit's Quickbase is a very healthy business, because they have a channel to millions of SMBs. We didn't, and didn't know how to build one, so we grew much more slowly (though I should say that by most sane, non-valley standards we were doing just fine, thanks ;)

I learned a lot of things at Dabble, but I think the biggest lesson was that the three most important things in B2B software are distribution, distribution, and distribution.

I think that you're right about the intent of the author, but unless I'm mistaken, that's not what the code does. If _ok is false, it boils down to if(!(Math.random() > 0.1))) which is the same as if(Math.random() <= 0.1), which means it will return early only 10% of the time, so the exception gets logged 90% of the time.

Wait, what?

I'm a ferry ride away on Galiano; could possibly make some meetup. avi@stripe.com.

People interested in this might also want to check out simmer, which provides a simple unix stdin/stdout interface for this class of bounded summaries of unbounded streams. Quantiles are actually a weak point for simmer right now (I have a TODO item to add Q-Digest), but it has a bunch of other useful sketches implemented, via the Algebird library which I also hack on. Would love to get feedback & patches. https://github.com/avibryant/simmer

Nice slides. You should check out https://github.com/twitter/algebird - we've implemented a number of streaming algorithms (HyperLogLog, Count Min Sketch, along with stuff like minhash and bloom filters) in Scala as Monoid typeclasses. Love to hear your thoughts or get your contributions.

Etsy - Remote - Hadoop

I'm looking to expand the team that makes Etsy's big data infrastructure awesome, reliable, and easy to use, supporting search, personalization, analytics, and many other product teams throughout Etsy. We work primarily in Scala and Ruby on top of Hadoop and Cascading. We have a strong culture of investing in developer tools and open sourcing them when they're ready: check out https://github.com/etsy for examples of what we're contributing to. It doesn't matter where you live, though being in the same time zone as the continental US would be an asset. Ping me at avi@etsy.com if you're interested.

Yep, though a feature request I've put in is to respond to a ctl-c by producing the results from the stream so far... that way if it's taking a while on a large file you can interrupt and still get something useful.