Hey HN, we just rolled out our first remote MCP integration. Starting today, you can check it out at claude.ai or Claude Desktop by adding Plaid MCP as a Remote MCP server: https://api.dashboard.plaid.com/mcp/sse (you have to be on Claude Enterprise, Team, or Max plans to access. Pro access coming soon.)
We're shipping with the first couple developer-focused use cases: conversion optimization and visual analytics, API usage monitoring and trend identification, and troubleshooting + diagnostics.
If you use Plaid, check it out, and we’d love to hear your feedback! Also happy to answer any questions on building out remote MCP servers generally (in Golang ;) )
Moving is one of life’s most stressful events. We empower people with a simpler, more thoughtful approach to buying or selling their home.
We have an amazing team of talented and passionate engineers and data scientists. We are looking for Machine Learning Engineers, Data Infrastructure Engineers, and Generalists to help us change the real estate industry. Leadership experience is a plus.
Technologies we work with: Rails, React, React Native, PostGIS, Python, AWS, Webpack, Phoenix (Elixir), Kubernetes, Docker.
Moving is one of life’s most stressful events. We empower people with a simpler, more thoughtful approach to buying or selling their home.
We have an amazing team of talented and passionate engineers and data scientists. We are looking for Machine Learning Engineers, Data Infrastructure Engineers, and Generalists to help us change the real estate industry. Leadership experience is a plus.
Technologies we work with: Rails, React, React Native, PostGIS, Python, AWS, Webpack, Phoenix (Elixir), Kubernetes, Docker.
At Opendoor we’re changing the way homes are bought and sold.
Moving is one of life’s most stressful events. We empower people with a simpler, more thoughtful approach to buying or selling their home.
We have an amazing team of talented and passionate engineers and data scientists. We are looking for Machine Learning Engineers, Data Infrastructure Engineers, and Generalists to help us change the real estate industry. Leadership experience is a plus.
Technologies we work with: Rails, React, React Native, PostGIS, Python, AWS, Webpack, Phoenix (Elixir), Kubernetes, Docker.
I'm super curious how Stripe approaches end-to-end testing (like Selenium/browser testing, but maybe something more bespoke too)
My understanding is that they have a large external dependency (my term: "the money system"), and running integration tests against it might be tricky or even undependable. Do they have a mock banking infrastructure they integrate against?
This is a great question, and it's definitely a problem we have.
We don't have a single answer we use for every system we work on, but we employ a few common patterns, ranging from just keeping hard-coded strings containing the expected output, up to and including implementing our own fake versions of external infrastructure. We have, for example, our own faked ISO-8583 [1] authorization service, which some of our tests run against to get a degree of end-to-end testing.
Back-testing is also incredibly valuable: We have repositories of every conversation or transaction we've ever exchanged with the banking networks, and when making changes to parsers or interpreters, we can compare their output against the old version on all of that historical data.
>Back-testing is also incredibly valuable: We have repositories of every conversation or transaction we've ever exchanged with the banking networks, and when making changes to parsers or interpreters, we can compare their output against the old version on all of that historical data.
Are you referring to test data or actual live transaction data? The latter would seem like a huge liability and target for hackers.
Live data, but they're stored redacted, and/or with sensitive data (e.g. credit card numbers) replaced with opaque tokens that reference an encrypted store that's carefully access-controlled.
Do you have any policy or decision made on how long you plan on storing that data? What I'm wondering, are the transactions currently "stored indefinitely"? (I'm referring to both data stores. The tokenized and the encrypted one)
> ranging from just keeping hard-coded strings containing the expected output, up to and including implementing our own fake versions of external infrastructure.
This sounds very familiar, we rely on external credit systems pretty heavily. We started by mocking service responses and including the response XML in our unit tests. Now we have a service simulator that returns expected values and has record/playback capability. It's not ideal and responses get outdated occasionally but we haven't found a more elegant way to handle it yet.
I'm very curious about that as well. I worked on a big project that had a (perhaps analogous) large external dependency on networks of embedded devices in homes and businesses, and integration testing it was …difficult. I'd love to hear how Stripe solves that problem.
That's basically what we did, but more like mocking things at the network communication boundary. But for an integration test, it was often unsatisfactory, because of things behaving differently than they do in the real world. We also had a suite of automated tests that communicated with real devices in a lab, which were much better, but extremely hard to maintain. My general experience was: tenable, but tricky. So I'd love to hear how others have handled similar things.
Was it not possible to build upon the mock device to make it run more realistically?
I pretty much do this habitually now:
1. Get report of bug in production or on staging.
2. Write test to reproduce the bug.
3. 2/3 of the time get stuck because the environment isn't capable of mimicking the bug.
4. Build upon the integration testing environment to make it capable of mimicking the bug.
I find the counter intuitive part of integration testing is that step 4 ends up being where most of the work is required and far too many people just don't do it because they feel it's not a worthwhile investment.
I actually ended up writing an open source framework to handle a lot of the boilerplate (which no other frameworks do AFAIK). Especially making mock devices easier to write (see http://hitchtest.com/ and check out HitchSMTP).
> I find the counter intuitive part of integration testing is that step 4 ends up being where most of the work is required and far too many people just don't do it because they feel it's not a worthwhile investment.
That's all I'm saying: tenable, but difficult (read: expensive). Frankly, I'm not convinced it is a worthwhile investment. Hence, my interest in how others have approached a similar problem.
Hitch looks pretty nifty, but I'm not sold on the yml/jinja2 approach. I grew to loathe Cucumber, and this approach seems similar. If you can't convince your non-technical staff to write tests in this language (which, in my experience, you can't), then you're better off writing the honest-to-god code that programmers are comfortable with (and can more easily modularize and refactor). YMMV I suppose!
I don't like cucumber either. I dumped it on a previous project and just wrote code instead which I found to be easier too. In many ways this project was borne out of the frustrations I felt.
YAML is different. It has much clearer syntax and the method mapping is super easy and can even easily handle more complex data structures being passed in in the steps (lists, dicts, lists of dicts, etc.) which Cucumber either couldn't do, or required tortuous syntax and horrible regexps to do.
I did it this way mainly to adhere to the rule of least power and to enforce separation of concerns between execution code and test scenarios. Readability by non-programmers is just a nice side effect.
I suppose one day I might make a GUI to generate the YAML - maybe then non-technical staff might write tests, but probably not before.
Not a stripe member but i would assume that anything that involves intense security auditing, PCI, etc would be seperate codebases that rarely change.
(eg cc handling could anon the CCs in a service before they reach the main app)
The integration with 3rd parties is a seperate issue that exists no matter of it is banks or not - i would guess they abstracted that as well as services or libs and decide case by case.
Wow, this is an interesting/refreshing development from Apple. I can't recall them ever having a public blog to communicate with their developer community. Until now, it's mostly been through their developer forums, private support, and in-person at the yearly WWDC.
How they've developed as a developer-facing company this year is really encouraging. Google et al have always been transparent as glass relative to Apple's iOS work, but this blog, the twitter dialog from Swift's development team, and the no-NDA release of iOS8 has really changed my opinion of the direction they're pushing the ecosystem.
Surfin' Safari (https://www.webkit.org/blog/) is another great Apple developer blog. I followed it religiously back when Webkit was leaving everyone else in the dust.
Well, let's just wait and see, because frankly, I'm tired of reading marketing fluff like "We can’t wait to see what you build!".
After years in the making (which means plenty of time to think of an answer), one of the most important questions still hasn't been answered, and not even mentioned on the blog.
Namely, will Swift be open-source and submitted to standards bodies? Will key libraries also be released?
If I make an investment to learn Swift, what are the chances that I can take this knowledge and use it outside of the Apple ecosystem? Or is Swift destined to follow the fate of Objective-C and be completely useless outside of Mac/iOS apps?
I may yet be disappointed but I'm expecting them to open source it after release as they do with the other LLVM changes they make.
I think it could work with anything based on C libraries (C++ linkage sounds a bit trickier) but it has been very much designed to operate with the Obj-C libraries.
It might be that Haskell is a language to learn and may help you develop functionally if you switch to Swift later. There isn't that much to learn about Swift itself really.
Seems fairly transparent: members of the team would like to make it open source closer to the release, but they haven't made a decision yet and will likely do so once the 1.0 release is complete.
I did phrase that terribly. What I meant (and failed) to convey was that the most authoritative source of info on this topic was a post to a relatively obscure LLVM-related mailing list, rather than any sort of official announcement. However, I shouldn't have said "lack of transparency", because the devs could have chosen to not make any sort of public statement at all.
Considering that Swift is built on LLVM, it's not surprising that a comment was made there. It's also probably where an announcement of it being open source would be made (and now probably the Swift blog).
I've heard from various people that any decision on open source wouldn't happen until after 1.0 since the language syntax decisions haven't been nailed down yet.
Interesting thread. Not buying Chris's (with his Apple hat on) answer though.
The idea that you spend a few years to create a new language and have not even had a discussion yet about whether or not it will be open source is simply not credible.
Unless Swift was rushed to release because companies like Apportable were making too much progress and they wanted to herd developers back into the pens with new proprietary languages and APIs e.g. Metal.
Maybe they just don't want to deal with open sourced stuff for 1.0 Reference the arm64 stuff, I bet that the situation is that swift is in heavy flux (which if you follow Chris Lattner on the apple forums you realize they're changing things like crazy right now) and they just don't want to deal with people contributing to something that isn't quite ready. They already committed to saying they will introduce breaking changes in future releases. Maybe the whole team just doesn't have the time to deal with it, who knows, lets wait. Its not like C# suffered by not being open source from the start.
I wouldn't put that past Apple. Remember the more we antagonize them the more likely their legal team might go "not worth the effort just keep it in house".
Have you ever worked at a company that open sources code? I mean it's fairly common, even VERY common that the devs are all for open sourcing the product but the legal department has not made a decision yet. Engineers move at an incredibly swift, no pun intended, pace but Lawyers tend to take glacial ages to decide anything. It's completely and totally credible that the legal department hasn't given their final ok on things, especially at a company like Apple and as large as Apple is.
I hope/expect the out-of-box performance will improve over time, but I guess it shouldn't be taken as fact that Swift will always be faster than its predecessor.
> In fact, Swift is really built on top of Objective-C, somewhat similar to how Objective-C is built on top of C, and somewhat similar to how C is built on top of assembly.
Apparently, this is not exactly the case:
> not [Objective-C] under the hood so much as on the side. Swift has its own (relatively minimal) runtime. [1]
> Swift interoperates with the ObjC runtime. It's not dependent on it. [2]
I believe this means that one day Swift could drop the Objective-C runtime & dependencies, perhaps in favor of a Cocoa evolution that doesn't rely on KVO, selectors, etc.
