ABAP

Right - it should have been:

document.querySelectorAll('span#copyright_year').forEach((el) => { el.innerText = new Date().getFullYear() })

so that we update all spans with that ID!

Well… No new ones, at least? Though it was around that time that I started hearing whispers in the night… “You can use WASM to ship Client-Side PHP”

I’ve once written a JS decompiler (de-bundler?) using ~150 regex for step-wise transformations. Worked surprisingly well!

Imma do it this evening, so hydrate up, bud

Just as a warning, the macvlan stuff isn’t well documented and seems to have hard limits. I worked with it a couple of years ago and had to eventually read a lot of Docker code to figure some stuff out, and the host was only able to successfully set up 4 macvlan networks at a time - the fifth (and any following ones) were never reachable, even though I used the same scripts as for all other ones.

Things might have improved in the meantime.

https://github.com/facebook/prop-types/blob/4de0644a10a554d0a556daa39f029369bc007ea5/lib%2FReactPropTypesSecret.js#L10

Crazy what other commenters are coming up with.

Just make sure your friends are doing okay, and you’ll be good

Not in my code

I sometimes use n as my loop variable (⌐■_■)

The Podman developers did contribute to Docker for a while before starting the project. Docker kept introducing issues and had some fundamentally bad design decisions that they didn’t want to change.

At least try to look into the history of these things before making broad and easily falsifiable statements.

Podman wasn’t built due to NIH. Docker has real problems (though many have been fixed), and Podman was built to fix those.

Nah, it’s actually publ;c

And you know with 100% certainty he hasn’t had a single memory bug in his last decade of developing?

The inevitable cycle of modern open-source text editors. First there was Atom, then that got too slow and most switched to VS Code. Next seems to be Zed… I wonder what comes after it!

Please show me a single “good” programmer who is working with C/C++ and hasn’t had a single memory bugs in a decade.

It’s not necessarily awful by itself (though this is not a production-ready implementation). shit is the name of the project, Shell Git.

Always read mails really fast

Are you a Prisma fan?

Ooooh, that’s a good burn

I am happy with my simple docker-compose setup - one root folder with one subfolder per project containing the compose file and any configuration mounted into the container. Traefik automatically exposes all services I want under a well-known URL using a single line in each compose file. Watchtower updates the containers.

This has been running stable for over two years with probably 2-3 reboots in between. If my current NUC ever breaks I’ll set it up again using Podman instead of Docker, but aside from that I couldn’t be happier!

Very understandable :)

An easy fix for this is to create individual networks for connections. I.e. don’t create one network with Gitlab, Redmine and OpenLDAP - do two, one with Gitlab and OpenLDAP, and one with Redmine and OpenLDAP.

To explain this a bit further, the main difference between older jQuery-based projects and newer (React|Vue|Angular|Svelte)-based projects is imperative vs. declarative programming.

It used to be that you give commands (e.g. “when the user clicks this button, change that label content and add CSS classes to these elements”). Very quick to add something small, but also hard to grow and maintain well. It’s easy to forget a command in some code paths.

Nowadays you declare state, and define how your UI is derived from that. This means you don’t give commands to change things, instead you change data and your UI is updated automatically. This makes it much easier to understand a component, and allows for maintainable growth.

Typescript! Though it’s less useful, since the Typescript types aren’t available at runtime, so you’ll just get object for non-primitive values.

Ah, that’s understandable. Sorry you have to go through that!

That’s… Surprising. If you’re doing things right, double quotes should be no trouble at all:

• HTTP requests have simple, automatic encoding
• SQL queries with prepared statements don’t need any special handling for double quotes
• Rendering the data should happen with proper escaping etc.

They are usually only trouble if you’re doing SQL queries wrong (concatenation etc.) or if you’re not escaping your output.

Types help you prevent errors while writing the code instead of while running. That’s a massive benefit, as it literally makes a lot of errors impossible (as long as you don’t work around it) - otherwise you have to write a lot of tests to get the same guarantees, and you could always miss something by doing that.

The other benefit is that it allows other developers to understand your code very, very quickly. Types describe what your data looks like - there is nothing more important in programming than that!

When you install an NPM library and your editor gives you hints about parameter types, return types etc., that’s all Typescript types at work.

I’m not sure why you’re bringing up efficiency, I’m not talking about that. If I don’t understand a topic, I can’t do things with the topic. I use Regexes, so I must at least somewhat understand Regexes.

I’m saying if you look at my code, and I write a lot of negative lookups in dev ops for data validation, you can’t read my code. It’s nothing personal.

Well, earlier you were saying that I don’t know Regexes if I don’t know reverse negative lookups. Funnily enough Regex101 would help me understand your code in this case, so you were wrong on that count too.

I have written dozens upon dozens of Regexes without using reverse negative lookups, but I guess according to you I don’t really know Regexes because I haven’t used those specific features?

You don’t need to know all about a subject to know a subject.

Does every Regex contain a reverse negative lookup? Do I need to know how to do a reverse negative lookup to write a Regex?

If not, why are you asking?

I taught myself Regex using Regex101, so something doesn’t add up here.

It’s really not too bad as long as:

• you use a proper IDE (e.g. Regex101) with highlighting and piecewise explanations

• you use named capturing groups

• you give the regex a descriptive name in your code

tar --extrahieren --volle-ausgabe --gezippt --folgende-datei

The type checking does, but not the compilation.

That’s because you’re missing the distinction between compiler and type checker. The compiler doesn’t check types, it strips them. The type checker only checks types, it doesn’t compile. They are often used in conjunction, though increasingly the compilation is done by e.g. esbuild.

But there is nothing “bizarre” about the code running, since literally, TS is a superset of JS.

In TypeScript, it fails. You can’t treat an object as an arbitrary key/value pair. That’s a good thing… but still, it means TypeScript is not a superset of JavaScript.

No, it doesn’t fail. It compiles to perfectly valid JS that runs exactly as you’d expect. The type checking itself errors, because you’ve made an error - but the compilation isn’t prevented by this error.

So yes, Typescript is a superset of JavaScript.

Yeah, if a CEO has to lie to make their product seem better, it’s blacklisted in my mind.

Thank you for the correction! Then it’s also wrong due to Gitea which launched in 2016.

Also plain wrong - Codeberg launched in 2019. Now the question is: did the author just not know better, or is he paid not to know?

You lose way more information during compilation than you do during minification. This makes reversing the latter much easier than the former.

Remember that JS is much, much higher level than WASM is. Each language will have their own special behaviours and constructs when compiled to WASM, so reversing an algorithm can look completely differently depending on the source language and environment.