m3h

Are they inviting you to apply?

And what happens if you do?

Yes, when taken in this context, the Monopoly argument makes sense:

> The DOJ said Visa imposed “exclusionary” agreements on partners and smothered upstart firms.

How does an external authorisation service work without the knowledge contained in the application’s database? And vice versa, how does the application make the efficient correct queries from its database when the authorisation information has been externalised?

Are there any solutions for one-man SaaS to handle payments from enterprise customers? I'm assuming that the preferred mode of payment here is through wire transfers after some kind of PO process.

SST[1] looks pretty cool. Does it replicate the entire infrastructure Vercel attempts to provide you regarding hosting (such as CDN, caching, etc)?

[1]. https://sst.dev/

Does AWS or any other platform provide the kind of deep integration Vercel has with Next.js (such as caching, edge endpoints, etc)?

Exactly! And that's what I want to design my problem for. But I'm not sure where to start. How complex of a problem can ChatGPT solve? And are there particular types of problems that are good at sifting through candidates to find ones with strong problem-solving skills but which remain GPT-proof?

This isn't my tool but based on what I read on the previous thread about it, it doesn't seem to be open-source. However, some folks recommended this tool which does seem to run locally: https://github.com/torakiki/pdfsam

I didn't create this tool, but I use it frequently. I'm also using uBlock Origin, but I don't see the issue you describe. I'm not sure what Badget is, though.

In that case, you can use https://www.pdftool.org/, which runs in the browser but offline and never uploads your files to any server.

>Firefox's masonry layout is in fact implemented in such a way that basically covers all layout cases

That's good to know.

I am wondering whether it makes sense to keep adding more "layout" options to CSS, given that we have the legacy floats and then the modern flexbox and grid layout. If there are still cases that are not covered, perhaps a better solution to to have one final constraints-based system that covers all layout cases, even if it comes at the cost of complexity. The CSS frameworks and utility libraries will then be built on top of it to provide the next generation of "masonry" grid, etc.

Thank you. I stand corrected on some points. The messy ecosystem of npm, yarn, pnpm, JS, TS, ES, and ESM has all cost me a good amount of white hair.

A good source of my confusion came with not immediately recognizing that a new package registry does not require a new package manager to work with. I think the "jsr" commands in the code samples and the jsr.json make it feel like there's a new package manager in play here. If the team has made it so that npm works with "jsr" and vice versa, kudos to them because that's a big win for the users.

Another comment in the thread makes a very good point:

> Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes.

Add to that the frequent compilation issues that happen as TypeScript adds or removes types in the global imports, changes language conventions, and updates compilation checks whenever a new version gets released.

As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause.

> You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility.

This sounds like another building service I don't control. There's already too much magic in publishing transpiled TypeScript packages but at least the current tools let me control exactly what artifacts get pushed out.

> web-standard ECMAScript modules

The "web standard" part is meaningless considering that most production websites will bundle the files together as part of their build/optimization process for size and loading speed, leaving only a giant chunk(s) that resembles nothing like the original ES modules.

> JSR isn't a replacement for the npm registry; it's a superset of npm.

A super of npm means that the packages created for this repository will not work in the npm ecosystem. What is this if not a "replacement" of the npm registry and further fragmentation of the JS ecosystem?

>JSR modules can be used with any JavaScript package manager, and in any project with a node_modules folder.

This makes the already complicated module resolution logic in most bundler/packaging tools even more complicated as they must account for the intricacies of another package manager. A house of cards being stacked on another house of cards...

> Module authors can count on great editor support from strongly typed modules, without the need to transpile and distribute typings manually.

The website seems to insist that distributing typings is a complicated process when it is just the .d.ts files bundled with the published package and an additional entry in the package.json file.

> Easy publishing with a single command - the CLI will walk you through the rest

It seems like every benefit that this project offers can be fixed in the current ecosystem by better client-side tooling that enforces standards during the publishing process while keeping full backward compatibility with over a decade of packages published and without fragmenting the ecosystem.

Could the solution to a complex cloud like AWS and Google be a simpler cloud like Digital Ocean is attempting to create? I find their offerings much easier to decipher and their onboarding journey developer-friendly. This is as opposed to AWS where I reckon a certification is needed just to navigate the mess of services it offers and to securely deploy those services without creating a security vulnerability for your organization.

Do you know of any similar application for Windows? I'm impressed by the quality of the video and the transitions. I am using an open-source tool (ShareX), but it does not offer similar quality or features.

I second this. Sublime text is one of the faster text editors out there. It boots fast enough that I use it as my go-to notes app.

Did I just break their conflict-free sync?

https://i.imgur.com/MiEWHA9.png

Nier Automata. It has some of the best story line, music and action in a game. It follows 3 Androids trying to reclaim the world for humans in a future dystopian world overrun by machines. There are many philosophical questions underlying the story and together with the music makes for an immersive game.

Steam has a very hard-core gamer feel to it. Just look at its interface. I do often admire the simplicity of Google Play Store. And I think a dedicated store for casual gamers is both a user experience and discovery issue. Steam solves neither of those because they need to sell "all" kinds of games and with that comes the baggage of years of market choices like DLCs, game "editions" and bundles. Google could just go straight to "Click, Pay and Play".

It doesn't seem to be available in my region yet.

The openness of PC means that a second app store can exist and be successful on the Windows platform. If Google pulls this off, we might see a credible, large store of casual games on Windows for the first time. Right now, mobile shines for casual games and sees the bulk of investment for casual games. It would be a great boon for many casual gamers to be able to switch devices and carry over their games to the PC to play it on a larger screen, possibly with a controller.

It would be great to have some examples right on the main page as many devs would be interested in how this library compares to the React/Vue/Angular/etc. Currently, the code samples are hidden two levels deep and behind a view source button.

Hello all! I'm one of the creators of sdks.io over at https://www.apimatic.io/

Happy to answer any questions!

We started this project at APIMatic to share our learnings about building and generating SDKs with the API community. We have helped dozens of API providers generate and deploy SDKs now used by millions of developers, giving us some confidence in the learnings we share in this resource.

Next, yes, it is hard to create and maintain production-ready SDKs for a large web API. There are so many open-source Code Generators for OpenAPI that aim to address this, but we found that they often do not follow the best practices for the languages they were generating SDKs for or did not create resilient SDKs. We cover both practices for ensuring a good developer experience for SDK users as well as methods for creating SDKs that help users to production-ready integrations faster.

Finally, while we are building a tool that we think solves the SDK problem for most API providers while following the best practices, we are still interested in creating a resource for folks who want to write their SDKs by hand, a kind of resource we ourselves wanted when we first started designing SDKs. We hope that this resource will be a time saver for those starting their API program today.

Thank you for the idea. We do know some parts of code where we have issues which might be good candidate for the interview.

Apart from this, do you have recommendations or ideas for the take home tests for frontend engineer interviews? In a previous hiring run, the test we used turned out to be too easy because all candidates were able to implement it successfully and offloaded work heavily to third-party libraries.

It is harmless fun.

It seems like webhooks have enough corner cases for the sender to require a specialized tool to protect itself from malicious users and to stay performant.

Does anyone have suggestion for such tools/services that they might have used in production?

That's something that we are doing at APIMatic already.

APIMatic[1] is a Code-Generation-as-a-Service[2] that generates SDKs for C#, Python, PHP, Ruby, TypeScript and Java from OpenAPI specs (and more formats). We help companies create a better Developer Experience[3] for their APIs using SDKs and API Documentation that are always up-to-date with the API implementation. We have a pretty solid customer base[4] and SDKs generated using APIMatic have been downloaded millions of times.

PS: My email is in my profile.

[1] https://www.apimatic.io

[2] https://alpha.apimatic.io/continuous-code-generation/

[3] https://www.apimatic.io/developer-experience-portal

[4] https://alpha.apimatic.io/success-stories/

No, we built our first code generator from scratch in 2014 [1]. I don't think most of these projects existed at the time. Our current CodeGen has always been written-from-scratch, propriety code. Our focus is also a bit different from these projects: we aim to cover as much of the OpenAPI format feature-set while generating consistent, high-quality, well-designed SDKs (should be as good as a good engineer can produce). To complete the Developer Experience of the API, we also generate complete API documentation site as well [4].

Back in 2014, OpenAPI didn't even exist. The latest API specification format was Swagger 1.2 and it was not very mature at that point. We had to build a lot of vendor extensions to cover the various REST API use-cases that API folks take for granted today.

Today, we also run the most-used API Spec format convertor tool in the world by the name of API Transformer [2]; this tool has helped a lot of companies migrate from an older spec formats like OpenAPI 2 and RAML to OpenAPI 3. We support nearly all API specification formats including RAML, OpenAPI (2., 3.), Blueprint, Postman, WADL and more.[3]

[1] https://www.apimatic.io/about/ [2] https://www.apimatic.io/transformer/ [3] https://docs.apimatic.io/api-transformer/overview-transforme... [4] https://www.apimatic.io/developer-experience-portal

I recently wrote a blog to help teams decide between writing the SDKs for their APIs by hand or generating them using a code generator: https://www.apimatic.io/blog/2021/09/the-great-sdk-battle-bu...

TLDR: There are a good many technical challenges to creating high-quality SDKs in multiple languages for a medium to large-sized REST API and most teams seem to underestimate the amount of effort required to build and maintain SDKs. The speed and savings from code generation is quite compelling and a modern commercial code generator like APIMatic has a wide-enough feature-set that most REST APIs don't require writing SDKs by hand anymore.

Disclaimer: I am a contributor to APIMatic Code Generator.