frew
Joined 15 years ago
Karma
162
Submissions
44
Member since
May 24
Recent submissions
Comment · 4 years ago
I don't believe so, but we target everything in the Webkit ecosystem (Chrome, Edge, Safari), so Firefox would be the only odd browser out.
Comment · 4 years ago
The fundamental motivation for the app id concept is that part of the value that InboxSDK provides is cushioning the developer from version conflicts, both from Gmail updates and from multiple extensions that all use InboxSDK. So we use app ids + a custom error reporting mechanism to aggregate anonymized error reports in order to figure out incompatibilities + reach out to the developer as appropriate.
You're welcome to make the app id opaque. Also feel free to file an issue for making a setting to disable the app id - definitely not opposed to adding it as an option given interest.
-Fred
Eng @ Streak
Comment · 4 years ago
It does! That was actually one of the motivations for open-sourcing.
Comment · 4 years ago
Cost was definitely a consideration (although not the only one) in deciding whether to store all created links vs. just a blocklist.
Once we got to a mode where we were only doing computation per request, the raw cost is pretty minimal since there's not much CPU time either way.
Comment · 5 years ago
This is impressive! For folks who are worried about what this says about App Engine's security - historically the JVM level sandboxing was one part of an overall sandboxing story (not surprisingly, very similar to Chrome's setup) and my understanding, although haven't been on the team for a decade at this point, is that the JVM-level restrictions have been effectively replaced by a gVisor-based solution.
Comment · 6 years ago
Comment · 7 years ago
It looks like the play here is to get a bunch of small, committed workloads that GCE can move around where they've got spare capacity. On-demand pricing is very similar to the existing n1 type, but 1yr committed discounts are 30%+ cheaper.
More details from when I was working through it: https://twitter.com/fredwulff/status/1204861220165017600
Comment · 7 years ago
Streak | YC S11 | Engineering Manager | Vancouver, BC & San Francisco, CA | Full Time | Onsite
Streak is hiring our first dedicated engineering manager who will be directly responsible for some or all of our engineering team (currently ~15 engineers, distributed between product, infrastructure, and mobile).
* Problem: Make Gmail powerful for all businesses
* Product: We build a sales/hiring/fundraising/dealflow tool all inside Gmail. We believe these workflows belong entirely in your inbox because thats where people spend their entire day.
* Traction: Product market fit, hundreds of thousands of users, tens of thousands of paying users
* Funding: $2M seed, profitable and growing ever since
* Stack: Java, Kotlin, Golang, React, all the modern JS tooling - built on GCP, largest user of Google Cloud Spanner
Comment · 8 years ago
(I'm the author of the post - just woke up and saw this discussion. Hi!)
Will put together a follow-up with some more information, but in summary: * yeah, no built-ins for graph operations in Spanner other than relational SQL for standard joins * the key thing that make this work are the ability to easily construct global indexes that aren't sharded by the primary key and reasonably fast joins between them * it's also helpful that Spanner does a reasonable job of parallelizing queries (e.g. a lot of times we'll get a 15x increase in speed vs. a sequential plan) * we then do the fan-out across the graph in our Java Spanner client - each distributed SQL index read takes ~10 ms so we can do multiple round trips of graph traversal in the client
Comment · 8 years ago
(I'm the author of the post - just woke up and saw this discussion. Hi!)
The intention wasn't to hold out Spanner as a purpose-built graph database, but rather to talk about using it for a graph-y database use case. Will put together a follow-up with some more information, but in summary: * yeah, no built-ins other than relational SQL for graphs * the key thing that make this work are the ability to easily construct global indexes that aren't sharded by the primary key and reasonably fast joins between them * it's also helpful that Spanner does a reasonable job of parallelizing queries (e.g. a lot of times we'll get a 15x increase in speed vs. a sequential plan) * we then do the fan-out across the graph in our Java client
Comment · 8 years ago
(I'm the author of the post - just woke up and saw this discussion. Hi!)
Definitely wasn't meaning this post's title to be clickbait-y. The intention wasn't to hold out Spanner as a purpose-built graph database, but rather to talk about using it for a graph-y database use case. Will put together a follow-up with some more information, but in summary: * yeah, no built-ins other than relational SQL for graphs * the key thing that make this work are the ability to easily construct global indexes that aren't sharded by the primary key and reasonably fast joins between them * it's also helpful that Spanner does a reasonable job of parallelizing queries (e.g. a lot of times we'll get a 15x increase in speed vs. a sequential plan) * we then do the fan-out across the graph in our Java client