That’s the kind of thing I suspect as well. Thank you for sharing your insight/experience. It’s always interesting and valuable to hear others experiences.

How’s it going so far?

The solution to this problem. . .

is that they have to create a support ticket with you, that you then put in progress, and you walk them through your documentation, and then log your time spent onto that ticket. (/s)

There’s an alternative to creating too many tickets that only add overhead and then make it harder to get into the project. Creating a good amount of tickets.

I took the OP reference as demand for ticket creation when they don’t make sense and only hinder development through unnecessary overhead. E.g. creating a ticket before a quick analysis, or creating individual tickets when one story/feature ticket would be enough. Or more specifically in this case, having to create one before fixing a critical blocker.

EoD? End of December? End of Death? (reference to world going to end)

man oregano => https://man.cx/oregano

oregano - GNOME application for schematic capture of electrical circuits

I doubt it is about that though…?

given how dynamic creation it looks maybe it has to be executed/included rather than imported and then the class is available?

With all that magic, and looking at https://join-lemmy.org/api/index.html if you’re not using pnpm I would give up on that lib.

One table of percent increase/decrease written into SEVEN worded paragraphs. That’s how you add bloat and reduce overview and comparability.

The percent numbers aren’t telling. They don’t explain the methodology of how interest has been measured. Which could have added value to just writing out the numbers. The huge numbers of multiple hundred percent indicate to me that they’re worthless numbers.

The title is bullshit too. They say interest in C and C# was up, contradicting their claim that traditional programming language interest is declining. Clickbait non-content.

The note on Googles CEO claiming 25% of their internal code is now AI generated was surprising and interesting to me. I don’t know if I find it surprising, shocking, or implausible (suspecting the CEO misunderstands or misattributes what is happening; sourcing is not applied code).

choosealicense.com is great for an overview of common licenses.

https://github.com/doitsujin/dxvk/releases/tag/v2.5.3

deleted by creator

That js file certainly doesn’t look like a normal module to me that I would expect when importing a module.

But I’m not too familiar with the JS ecosystem to the point where I know what that dynamic Object.defineProperty(exports, "__esModule" magic does or how it’s supposed to be used.

But I can see why the import would result in undefined.

With my first search of LemmyHttp I land on https://join-lemmy.org/api/classes/LemmyHttp.html, which says Defined in src/http.ts:153. Have you considered importing http.js? Looking at the http.js on the CDN I can at least see the LemmyHttp class type you seem to try to import.

Maybe include your “add it” and “the library turned into undefined” code as a minimum example?

So people can actually check your assumptions and actions and match it against the lib.

Maybe automated conversion as an upgrade path would be a lower effort with not the same, but similar usefulness.

The suggested solution is flawed and infeasible.

They criticize search engines ranking and moderating their content. Splitting one search engine into an unfathomable amount does not improve that. It complicates it.

Offloading assessment and decision-making of choosing trustworthy to the user is infeasible. They choose a search engine because they trust them. Very very few people would actually explore and assess alternatives and create a ranking of rings and servers/providers. What you would end up with for most users is centralized meta-search-engines and you have your first problem again anyway, but much more convoluted.

The criticized SEO would still be a thing.

Search engines work well because keywords serve as “keyring” selectors, and a single engine can index all kinds of content.

None of this solves their problems. And the closing sentence shows that very well. Now there’s more problems then were listed as the premise.

Now the issue is moderating web-rings, users, web-ring sorting, web-ring federation, server ranking, server and user blocking, and more.

You’re much better off choosing your search engines.

Given the prevalence of NodeJS and its compatible tools and platforms, I can’t see it as a mistake.

Through compatibility, Deno established an upgrade path.

However since 2022, Deno is trying to imitate Node more and more, and this is destroying Deno’s ecosystem.

My impression was that Deno specifically does not try to nor want to imitate Node. They specifically announce and document their intended tooling and ecosystem which is different from the NodeJS and NPM ecosystem.

Their reasons for NodeJS support is for compatibility and enabling users of those platforms to use Deno.

Without it, I don’t see Deno replacing NodeJS in a considerable manner. Now, it’s a possibility. (But the sheer volume and prevalence still makes it seem unlikely.)

https://codeberg.org/lig/todo-md/issues/4

I didn’t create one because I won’t be using the project, but suggested it here for your consideration. :)

Outside of work-in-progress or exploration branches, I don’t commit or merge TODOs. Typically, I consider them merge/land blockers. Because most of the time, they’re never resolved. And in that case, I much prefer documentation and statements; reasoning of why it is the way it is, or opportunities.

Maybe you want to scan for FIXME: too?

I’ve read interesting argumentation against nesting. I’m not confident in whether it’s more useful or not, in some situations or in general.

praise thy