wearhere

I too was surprised to read that they were syncing what reads, at a glance, to be their entire database into the data lake. IIUC the reason that Snowflake prioritizes inserts over updates is because you're supposed to stream events derived from your data, not the data itself.

I was hoping to open this and see screenshots of what the OS looked like—I have never had a sense of what the OS for Meta's headsets is, only what individual games look like.

Instead, we get five (5) "Not an actual product render" illustrations.

This article barely describes why the mushrooms did _not_ eat Luke Perry, despite acknowledging that up top. All it suggests is that autolysis enzymes kill the mushrooms?

Also Swift!

This reflects astonishingly poorly on Brex. What customer wants to hear that Brex is using "a non-deterministic model" for "production use cases" like "staying on top of your expenses"? I don't see them acknowledge the downsides of that non-determinism anywhere, let alone hallucination, even though they mention the latter. Hallucinating an extra expense, or missing one, could have serious consequences.

This is also potentially terrible from a privacy standpoint. That "staying on top of your expenses" example suggests that you upload "a list of the entire [receipts] inbox" to the model. It _seems_ like they're using OpenAI's API, which doesn’t use customer data for training (unlike ChatGPT), but they should be crystal clear about this. Even if OpenAI doesn't retain/reuse the data, would Brex's customers be happy with this 3rd-party sharing?

The expenses example seems like sloppy engineering too—there's no reason to share expense amounts with the model if you just want it to count the number of expenses. Merchant names could be redacted too, replaced with identifiers that Brex would map back to the real data. These suggestions would save on tokens too.

Despite Brex saying they're using this in production, I suspect it's mostly a recruiting exercise. It's still a very bad look for their engineering.

This headline may technically be correct, but it sure does suggest a bit more than what's being offered. "We're opening a sign-up page on our site"?? And (below [1]) Kyle mentions geofences?

How much of the public plans rides in advance, for a limited service area, via the web? I want to hear when these services finally have the capability and capacity to match the experience of Uber and Lyft: get a ride when and wherever you need one.

[1] https://news.ycombinator.com/item?id=30169708

The best thing to do would be to plow this money back into vaccine production and distribution, since that's the reason that the wealthy shouldn't be able to shortcut the process in the first place—it needing to work well for everyone.

What’s the timeline for Phase III trials? The article doesn’t seem to say. I don’t feel reassured that those won’t be rushed.

Yeah I do not understand why the author waited so long to disclose and also feels that Google deserves a "stellar job" here. Sure, Google patched the bug very quickly after disclosure. But given that Google waited so long, it sure looks like they only prioritized the fix once disclosure was a risk. If anything, I think that the author should have scheduled disclosure sooner.

What’s MCN?

It's crazy to me that the EU is wasting their time making Apple use the same ports as other smartphones (https://appleinsider.com/articles/20/02/02/what-the-eu-manda...) when they could make it easier to replace _any_ Apple component with an equivalent. I see the other comments saying that this guy deserved to lose this specific case since he was calling the parts "refurbished" but it's not clear that there's any way for him to use aftermarket parts legally.

Folks should know that this approach will not accommodate upcoming changes to Chrome extensions, which will disallow all remotely-hosted code: https://groups.google.com/a/chromium.org/d/msg/chromium-exte.... More up-to-date guide here https://developer.chrome.com/extensions/migrating_to_manifes..., with a timeline of 2020. I understand why

> one thing we wanted to prevent was developers including the stock SDK directly in the extension

(and I feel for Streak, having worked on a Gmail extension (Mixmax) until recently), but this seems to be exactly what manifest v3 will require. Curious if you have another strategy, @alooPotato.

Hey Venkat! Thanks for replying in good humor.

Now that you explain your reasoning a bit, and upon re-reading https://en.wikipedia.org/wiki/Serverless_computing, I think using "serverless" in this context makes sense. I see "serverless" used so much more often to describe compute runtimes like AWS Lambda than databases that, I confess, I thought you might be trying to ride that wave's popularity; and/or that you might be using "serverless" _just_ because the servers were managed by you not the users, whereas you allocate capacity on a more granular level than the server.

I do still recommend you take out the "cloud hardware" bit ;D

Thanks for the explanation, and best of luck! Cool model.

Calling a hosted database "serverless" is the most brazen branding I have seen in a long time. For extra hilarity, their pricing page says "pricing is inclusive of cloud hardware".

Mixmax | San Francisco or REMOTE | Full-stack engineer or INTERN in Winter/Spring/Summer '19 | https://mixmax.com/careers

We're a profitable, fast-growing startup looking for full-stack engineers (senior, new grad, intern).

Mixmax is the hub for all your business communications. We integrate with your company's existing toolchain - email, calendar, chat, CRM, and more - to bring all information into one place. This means we're syncing, storing, & indexing hundreds of millions events a day into our system, and then building fast APIs and delightful front-end UIs to make the data actionable for our users.

Try the product (it's free!): https://mixmax.com

We're developer friendly: https://developer.mixmax.com

Eng challenges: https://mixmax.com/blog/category/engineering/

Stack: Javascript, Node, Mongo, Elasticsearch, React, Go, AWS

Team fun: https://instagram.com/mixmaxhq

APPLY TODAY at https://mixmax.com/careers. Interview process: screen call, 1hr tech screen, 3hr interview.

Mixmax | San Francisco or REMOTE | Full-stack engineer or INTERN in Winter/Spring/Summer '19 | https://mixmax.com/careers

We're a profitable, fast-growing startup looking for full-stack engineers (senior, new grad, intern).

Mixmax is the hub for all your business communications. We integrate with your company's existing toolchain - email, calendar, chat, CRM, and more - to bring all information into one place. This means we're syncing, storing, & indexing hundreds of millions events a day into our system, and then building fast APIs and delightful front-end UIs to make the data actionable for our users.

Try the product (it's free!): https://mixmax.com

We're developer friendly: https://developer.mixmax.com

Eng challenges: https://mixmax.com/blog/category/engineering/

Stack: Javascript, Node, Mongo, Elasticsearch, React, Go, AWS

Team fun: https://instagram.com/mixmaxhq

APPLY TODAY at https://mixmax.com/careers. Interview process: screen call, 1hr tech screen, 3hr interview.

Pardon, we moved our website just last week and this link got dropped! Here you go: https://mixmax.com/careers/4023181002?gh_jid=4023181002

Looking forward to your application!

Pardon, we moved our website just last week and this link got dropped! Here you go: https://mixmax.com/careers/4023181002?gh_jid=4023181002

Looking forward to your application!

Mixmax | San Francisco or REMOTE | Full-stack engineer or INTERN in Fall '18, Winter/Spring/Summer '19 | https://mixmax.com/careers

We're a profitable, fast-growing startup looking for full-stack engineers.

Mixmax is the hub for all your business communications. We integrate with your company's existing toolchain - email, calendar, chat, CRM, and more - to bring all information into one place. This means we're syncing, storing, & indexing hundreds of millions events a day into our system, and then building fast APIs and delightful front-end UIs to make the data actionable for our users.

Try the product (it's free!): https://mixmax.com

We're developer friendly: https://developer.mixmax.com

Eng challenges: https://mixmax.com/engineering

Stack: Javascript, Node, Mongo, Elasticsearch, React, Go, AWS

Team fun: https://instagram.com/mixmaxhq

APPLY TODAY at https://mixmax.com/careers. Interview process: screen call, 1hr tech screen, 3hr interview.

Mixmax | Full-Stack Engineer or Fall/Spring/Summer Interns | On-site San Francisco (relocation provided), remote an option w/experience | https://mixmax.com/careers

We're a profitable fast-growing startup looking for all types of engineers: full-stack, backend, site reliability, data, machine learning.

Mixmax is the future of email and external communications. Just like you use Slack to talk within your team, you use Mixmax to talk to people outside of your team. Primarily, we help sales and recruiting teams achieve more and with greater consistency by automating their most common workflows and integrating with their existing toolchain - Gmail, Inbox, Salesforce, Slack, text messaging and more.

You'll work on a modern cloud-based web app built on universal/isomorphic Javascript using open source technologies, including: React, Node, Mongo, Elasticsearch, Electron (more: http://stackshare.io/mixmax/mixmax-for-web)

Check out our engineering blog: https://mixmax.com/engineering

Email [email protected] and let’s chat!

You can trust the browser itself (not application code, but the native code) to issue the appropriate headers. If you could find a way of compromising that, it would be a vulnerability wayyy beyond the scope of our protection.

(Caveat: browsers may not implement the specs completely/bug-free yet, as we cover in our post. But we fully expect they will, and in the meantime our module supports fallbacks. This approach is "skating to where the puck will be".)

Non-browser clients can spoof these headers, but the risk then is DOS, not clients leveraging the user's credentials—which is the primary focus of CSRF protection. It's nice that our method can prevent browser-based DOS attacks, but that's by no means complete DOS protection.

Interesting. But in both these cases (yours and @arkadiyt's) these vulnerabilities only affect GET requests right? In which case—though we would love to lock down GET requests, to prevent DOS attacks, and because GET routes _might_ in some cases modify state—the impact is pretty limited.

I (one of the co-authors of the post) would also characterize our approach as "skating to where the puck will be". I'm sure that browsers will patch these bugs, the Edge one was fixed quickly. Our product only nominally supports the latest - 1 versions of Chrome and Safari. This is of course a luxury not available to all developers.

Hi @codedokode, I'm one of the authors of the post. There's a lot of background material at the top but if you skip to the use of our new module (direct link: https://github.com/mixmaxhq/cors-gate/#usage) I think you'll find it simpler in both code and infrastructure than a typical CSRF setup. https://github.com/expressjs/csurf, for instance, requires you to lock down every API both server-side and client-side, and by default requires session middleware; whereas with cors-gate you can register it once, server-side, before any API routes.