Yeah I agree that it is impossible to know exactly what the fields are without a real documented source, but I figured this could be a decent option when there are no other alternatives available. While it's not perfect, it can provide a starting point for creating types based on sample data, which can then be refined as you work with the API and gain more understanding.
Tbh, there is no benefit of using this package if the API you are working with has an openapi spec, as there are other great libraries to help you generate accurate types such as https://github.com/openapi-ts/openapi-typescript. But I made this package to use when working with external apis that don't have an available spec.
Work day makes you input your entire work history into their structured web form anew for every job you apply to, there is no saved or transferred state.
I had a look at this, but the setup seems like it's for automated emails. I'm mainly looking to be able to personally send from the custom email without ending up in spam...
I think the obvious answer right now is anything related to AI. But I'm actually quite excited about the embrace of open-source applications that traditionally have not been, such as Cal.com and Mattermost.
I agree that open source, or even more specifically open and interoperable protocols between applications/sandboxes is where the next leg of software growth will happen on the internet. I don't believe increasing centralization is a trend but rather a swing of a pendulum that would start inverting soon. It will be less about open equivalents of centralized/closed products and services but just the birth of something new with openness and interoperability at the core.
Open source is trending up again these days. Lots of companies (like the ones you pointed out) are trying to be the cloud hosted offering of something that's open source. Love to see it!
It's sometimes important to remind ourselves that just because we can't see understanding in something doesn't mean there isn't understanding in it, and it might take effort on our part.
It's not a negative thing as much as an opportunity to grow if we ask ourselves to learn and see it as an opportunity.
The company I work at is fairly large, with thousands of engineers, and we use monorepos. It works extremely well. What about them makes you think it can't work?
We use monorepos in my company too, but we use one for each product, and it works really well for that. But for the whole company to be in a single monorepo just seems like it would require a lot of effort to maintain.
We have several projects per monorepo, and they are massive, currently being merged into a single one. Anything specific about maintainability that scares you?
If you aren't worried about partial checkouts & permissions
The biggest issue is deciding what to build across developers and their branches & products. You don't want to build the world on every commit, but you do want to ensure that you are building what the code would look like post-merge before the merge.
