ablanco

I think there are two main reasons to download from yt. The first one is that a lot of music is only available there. Services or torrents are not as vast as one would like when you are looking for something specific. The second reason is that services that provide offline usage are cumbersome to use in certain escenarios; eg: old car stereo

Given your experience, What's your opinion about ddg result quality?

I think Uber/lyft thought that self driving cars would arrive earlier than these regulations. Now they have to face a great difficulty to adapt to the new environment

I'm using it to port an auv3 plugin to a standalone app. The overall experience is amazing when compared to the constraint based method proposed in previous xcode versions. There are parts missing, but it's fairly easy to wrap uikit components and use them in swiftui

Overall I think it's a great step forward

this looks amazing! (beware on mobile for giant gif size)

SwifUI is a breath of fresh air compared to xcode builder, that giant unmergeable xml and the constraint madness where really clumsy to work with.

It's really sad that people (managers) still thinks of code this way. Luckily this has never happened to me, but if it did I think it would be a great sign to change jobs.

Sure, and they are great. But in some cases, it's inevitable to read some secrets from the secret management service to envs. This is what docker swarm doesn't allow with the 'docker secret' command

I don't agree at all. The reasons in the article all seem like "envs are bad because if you make a mistake you can expose them". This is not exclusive to envs, it applies to all secrets, independent of the medium used to make it available to the process using it.

In my experience, if you prevent using envs for secrets (as docker swarm does) all you get is a disgruntled programmer reading the contents of a secret file to an env in the entrypoint.

I don't think so. JUCE includes an audio/dsp engine. This is only for UI

In my point of view, most programming stacks are as hard as understanding the context they are planned for. Eg, It's much easier to learn a new JavaScript novelty ui framework knowing exactly where this piece you're writing will fall into. If you know the bounds of something it's easier to fill in the gap.

If you are learning frameworks just for the sake of it you'll have a hard time building something real.

I don't think this is a problem with git-flow, it's more a problem of using git-flow when you don't need it.

I use git-flow on projects that need to be installed by various different clients and there's no way to force all of them to migrate to the latest version, so you have to maintain support for older releases.

When the software needs to be installed in a single place and you can do it with CI/CD theres no need for the git-flow complexity.