frew

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.

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

It does! That was actually one of the motivations for open-sourcing.

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.

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.

Except it is: https://mail.gnome.org/archives/desktop-devel-list/2019-May/...

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

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 

(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

(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

(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

I'm the post author and happy to answer any questions people might have!

Does this runtime have access to the Standard APIs? It doesn't seem like the docs have any mention of Task Queue/Memcache/etc.

We (Streak) are based on a browser extension, but we're actually really excited about this launch since it works on the native Gmail mobile apps and it lets you install addons once and have them work across all your devices.

The graph itself is d3: https://bost.ocks.org/mike/sankey/

Based on random use over the past few years.

Redshift: Pros: Has the most adoption, so most integrations from SaaS services etc. are built with Redshift as their sink. Relatively fast and battle-tested.

Cons: In an awkward middle ground where you're responsible for a lot of operations (e.g. capacity planning, setting up indexes), but don't have a lot of visibility. Some weirdness as a result of taking PostgreSQL and making it distributed.

BigQuery: Pros: Rich feature set. Pay-per-TB pricing. Recently released standard-ish SQL dialect. Very fast.

Cons: JDBC driver is recent and doesn't have support for e.g. CREATE TABLE AS SELECT (as of a couple of months ago) so harder to integrate with existing systems. There are ways to run out of resources (e.g. large ORDER BY results) without a good path to throw more money at the problem.

Athena: Pros: Built off of the open-source Presto database so can use the documentation there. Pay-per-TB pricing.

Cons: Slower than the other options listed here. Very early product so lacking some in documentation and some cryptic errors. Not a lot of extensibility, but you could theoretically move to just using open-source Presto.

Haven't had a chance to evaluate Snowflake.

Used to work at Dropbox. Existing knowledge of new hires was 90% of the challenge with Mercurial with the other 10% being weird edge cases (e.g. very large/numerous repositories) that hadn't seen as much attention due to the smaller community.

Added a clarification to the relevant section. Apologies again for the confusion!

Apologies if I misrepresented Kafka's replication. So the system described in the blog post is the new 0.8.2+ stuff with min.insync.replicas taking over required.acks? Will review.

The cert on https://signed.bad.horse/ is also amazing.

corylouie is on Dropbox's security team.

(I work for Dropbox but don't speak for it in this capacity)

Returning accurate search result counts (i.e. "give me an exhaustive list of all pages that match this query") is at cross purposes to the main search problem (i.e. "give me the best ten pages for this query"). For the former, you want to be exhaustive, for the latter, you want to cut every corner you can to get results back as quickly as possible. Google optimizes for the latter at the expense of the former. Basically, don't put too much stock in any of the numbers you get back from Google.

Really great article and neat product!

One question: on the throughput graphs, I understand why you normalized them per graph, but were there any differences between graphs (particularly in terms of EBS vs. ephemeral) that would be sufficient to drown out the variability within the throughput graphs?

Hey Sean,

We looked into a lot of logging solutions and couldn't find a solution that fit our requirements. In particular, 1) at the moment we don't run any servers (even virtualized) ourselves, and we're loving not having to worry about that level of infrastructure. Splunk and most other logging solutions would have required running a VM just for the daemon (either proprietary or syslog). 2) the total cost of developing Mache was significantly less than even a single 500 MB Splunk license. 3) most other solutions that we looked at really want to treat logs as lines of text data. App Engine logs provide more metadata, and we didn't want to lose and have to reconstruct that data.

What product are you working on that it's possibly worth your time to test with FF 1? It's got like 0.01% marketshare at most. People mention IE 6-8 because large numbers of people are still on it due to corporate IT policies.

There's a saying that goes, "If you owe the bank $100, that's your problem. If you owe the bank $100 million, that's the bank's problem." In this case, that would be pretty much Google's problem.

Back of the envelope for the computers is what, $12k? Add in $2k or so for the TVs and you're at at about $15k. That's a pretty doable amount for someone without other expensive hobbies at ~$100k/year, which is around the starting salary for Google SWEs. So I guess if normal SWE compensation in the Valley is defined as wealthy then yes?

This is a good intention, but unfortunately the way copyright law works, having the license be ill-defined means that nobody can really use it and be assured that they're above-board, particularly in something like an Apache or GNU open source project, or in a company environment.

Unfortunately, there's not really a good, widely used license that does what you want, mostly because you run into problems pretty quickly based on derivative works with what you want. Let's say somebody merges your email client with a browser - can they call that by a different name? Can they sell that?

Anyhow, I'd suggest looking at looking at the Apache or BSD licenses (if you want the broadest use) or the GPL (if you want to ensure that modifications to the code must be distributed with any binaries made from the code). Licenses are a bit of a pain, but you can just pick one of the common ones and it'll really help adoption.

Definitely not superficial. Sorry for the long delay, but this now fixed. Thanks for the pointer. Let us know if you have any additional feedback.

Thanks for the feedback, and thanks for trying out the site!

We've found, both in talking to language teachers and in our own experience, that video helps communication and comprehension. However, it's definitely the case that for both privacy and bandwidth reasons, sometimes it's a liability. We don't require a webcam so for now you can just disconnect it if you're uncomfortable with it, but we're planning to add an option to intentionally omit the webcam feed in the future.

Thanks for the idea on topics; we've got a lot of ideas in that space, but we wanted to launch as soon as we had a viable product.

Glad you liked the call quality, it's central to many of the features we're hoping to introduce in the future. There's lots more coming. This is just the first step. :)