yeah, you can have github actions setup on arbitrary pushes to your branches, but there's not a good interface for linking actions to bare commits, and then having conversations etc. The place where that happens is usually a PR.
>it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc.
yes, and... the idea here is that it would be neat to extend the hermetic builds idea such that this can be run locally / anywhere where there's compute easily. The root problem that's being called out here is that idea of running something until the CI says it's green when there's a change, commit, network call, in the cycle is a pain in the ass. (The best way to avoid this churncycle is to just never write bugs! TFIC ;P)
Thanks. That's great! I especially like that it then lazy loads the blobs as you need them.
I was going to ask if there's a way to set that as the default but I guess I'll just set up an alias like I have for most of the subcommands I use daily.
I think it's rather hard because of their security & contractual requirements -- we had to sign a contract with them, go through security review, and so on.
We just this week launched a new sign-up flow to make it waaaay easier for non-businesses to use Plaid, I posted some details below.
Actually, as part of publicizing our new hobbyist-friendly onboarding, we're looking to work with hobbyists who have created Plaid-powered apps and would be interested in making a short video about their app and their Plaid experience to potentially be featured on the Plaid blog -- if you're interested, shoot me an email at ahoffer@plaid.com and I can send you the details.
Awesome. Definitely need to highlight this better somewhere on the main page (probably /pricing and in the /docs pages), but https://dashboard.plaid.com/ has it. More vague plans right now.
I would love this. I’ve built software to manage my business and personal finances and am using hacks right now (activity csvs for personal, quickbooks transaction api for business).
In an ideal world I’d move it all to plaid to help analyze finances, cc spend, etc.
I’m happy to hear you’re working on a hobbyist product.
I reached out to them a couple years ago with this exact question and was told flat-out no. You might be able to sneak around it with an LLC but I think they also require you to have a public website for a plausibly banking-related business, which altogether seemed like too much effort to fake for what I wanted out of it.
So you don't have to be a business to use Plaid, but you do have to be a business to buy Plaid via the Sales channel rather than via the self-serve channel. Admittedly, when folks reach out to Sales and ask to buy Plaid and are told they're not eligible because they're not a business, this nuance is sometimes not communicated very well (or at all). We're working on it. :-)
In fact, we actually just this week launched a new sign-up flow to make it waaaay easier for non-businesses to use Plaid, so try checking it out -- after you go to dashboard.plaid.com and create an account, you should see a "Free trial" button show up on the homepage with a link to use the hobbyist onboarding flow.
Correct, sales encourages you to sign their minimum contract, which basically gets you better support and an account manager. Pay as you go is an option, but Plaid indicated you basically wouldn't have any guaranteed support SLA post-launch if you were on PAYG.
Thank you for the info! Is this a somewhat recent change or has it always been this way? "A couple years ago" in my comment was doing some heavy lifting, I probably reached out around 2017ish.
> Don’t meet your heroes. I paid 5k to take a course by one of my heroes. He’s a brilliant man, but at the end of it I realized that he’s making it up as he goes along like the rest of us.
As a child and adolescent I always imagined that something would click when I became an adult and I would become good at things and understand the world. That never happened, and then I realised it never happens for anyone. We're all just large children walking around figuring things out. Some of us figure things out faster, some of us stop trying to figure things out, but we're all just as clueless in the grand scheme of things. It's a miracle and a testament to our perseverance and ambition that things still work as well as they do.
On the other hand, I've contacted several of my heroes (not been able to meet as many of them in person) and that's always been an exhilerating, formative experience. I strongly recommend it if you can think of a good reason. (I have a list of heroes I have yet to reach out to because I haven't yet encountered an interesting enough problem to offer them. Several of them unfortunately have an actuarial deadline not too far into the future.)
Could this be from adults not being honest to children when they don’t know something? I’ve personally seen this happen a lot. Many adults try to save face about not knowing things with other adults, let alone with children. So it might be a cultural issue that could be fixed.
I once worked with someone well renowned in my circles who gave talks, ran a blog, was cited/edited other peoples books.
His code did not match the hype, to say the least. His SDLC even less so.
There is probably an ego associated with being renowned that doesn't align with team-based work. He likened basic things like code reviews or PRs to being brought before The Hague and that the rest of the team was a bunch of bureaucrats.
I am not sure which profession they are in (software development?), but no. Not everybody is guessing. If they were you would have half of the buildings and bridges collapsing and the other half on fire by bad electrical wiring.
You can legitly learn how to do things properly and people who learnt to do that do the polar opposite of guessing. It is just that the world of software development has yet to be made liable for their results in the same way as civil or electrical engineers. So in software development many are just guessing because guessing wrong won't ruin their life.
Software "engineering" also differs in the way from more formal engineering in that there are very rarely absolutes, there's often many different correct ways to solve a problem, each possessing their own pros and cons. So, it could feel like "guessing" choosing a certain approach over another, but more senior people usually have an intuition brought from experience which one will work better and be more informed of the tradeoffs, so it looks a lot less like guessing.
Yet when we talk about controlling trains, airplanes, freight ships, medical devices, nuclear power plants and space stuff we suddenly know how to do it?
There is software engineering and it is known how to do things that absolutely must not fail. It is just thst these standard are not commonly deployed if nobody forces you to deploy them. And why would you? Costs money and a software error is widely treated like divine intervention.
There is a big difference between knowing something must not fail, and how to make it so it will not fail. The latter is where opinions and approaches often differ, in ways that more formal engineering does not.
I'm very wary of anyone in tech/software eng that says "this is the only right way to do this." I'm aware those attitudes exist everywhere.
I once found a very interesting definition of engineering. It is about making something that just barely does the job. Doing it better costs more usually and doing it worse costs lives.
Not much different in software. There is always many ways of solving problems and that is typical of any engineering. Contrary to sciences.
They are guessing much more than computer scientists would think, typically . A structural engineer does not know: the peak wind force, what the ground under the bridge is really made of, what the actual tensile strength at the weakest piece of material is, what the exact force on the screws were at time of fastening (and after), etc... Heck, they don't even know if euler bernoulli beam theory is actually right about the existence of a neutral axis..They just take their best guesses, add generous safety factors and have the bridge inspected regularly ..
You have abstractions and models for those things. I was formally trained as an EE, so I'm just guessing at how structural engineers do it.
I would expect someone building a bridge to keep the average/peak winds into consideration - and then feed it to CAD or whatever modeling software they use to design the structure. They don't need to know the exact force a screw was tightened with - they do need to give the specs of what range they should be tightened to. Again - considered in CAD. They don't need to know that theory is right - they just need to know it's not wrong to an unacceptable degree.
I'm sure there's some guessing, but a lot of these things are actually factored in.
reply