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?
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.
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.
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.
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.
> 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.
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.
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.
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.
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)