Both of these are basically strawman arguments - there are legitimate, non-tribal reasons to be against the actions taken re: tariffs and the purported anti-corruption tasks. For example, a person can be strongly against government corruption but also be strongly against the current efforts/methods being used for a multitude of reasons. And similar for tariffs. (Not having those debates here, just pointing out that I don't believe those examples hold up.)
As someone with 15+ years of experience, a lot of that FE specific, that is the advice I always give newer devs if asked. Learn the fundamentals of Javascript, HTML, CSS (it's like a 3 legged stool, even if the JS leg is oversized in the days of web apps). If you know how to program, and you know the fundamentals, you can work in whatever framework is thrown your way.
Now, practically speaking, that's actually probably better advice for someone with a job and 1-2 years in. To get an initial foothold in the industry, people often need to specialize in one specific thing (React at the moment most likely), in order to be able to demonstrate enough competence to get that initial job and so I understand how fundamentals can be backburnered initially. But I recommend devs don't let that initial success lock them into that framework - that's the time to get back and learn all the fundamentals, go wide, learn a couple other frameworks even so it's easy to compare and contrast the strengths/weaknesses of each.
And you will want to be well-versed in the framework you currently use day to day, knowing best practices, architecture patterns that work and those to avoid, etc. Knowing the fundamentals will help, but there will be framework specific things that will change from framework to framework, even code-base to code-base sometimes. So it's always going to be a bit of a balance. But long-term, IMO, being well-versed in the fundamentals affords you the most flexibility and employ-ability long-term.
Just adding on to number 4 - I didn't realize there was additional information explaining the pattern further below the interactive challenge for the first couple steps. When completed, it should then show the explanation and a button to continue.
I was excited to see this as just last night I was using FFmpeg to combine digital (legally owned) movies with multiple parts into a single MKV file. It worked great, the one thing (and this is undoubtedly just a knowledge problem on my part), is I could not get it to copy/include subtitles from both parts. I have a feeling I might need to extract the subtitle files and combine them and then re-include the combined version, but was hoping there would be a solution in this site for doing something like that. Unfortunately, I didn't even see the combine as one of the examples.
For reference:
One-liner:
> ffmpeg -loglevel info -f concat -safe 0 -i <(for f in *.mkv; do echo "file '$(pwd)/$f"; done) -c copy output.mkv
Or the method I ended up using, create a files.txt file with each file listed[0]
The scenario I was envisioning was a simple as a developer that worked at that startup added DankStartup email to their Github account, committed a bunch of code. Company shut down, but dev doesn't think to disassociate that domain/email. Malicious actor uses this technique to then sign into the Github account, gaining access to that developer's account, not just the DankStartup repos which were probably disabled after non-payment.
Now, obviously some fault in that scenario lay with the person who 1) used the same account, and 2) didn't remove the old email once the startup failed. But I'm just using that as a kind of example - there may be other accounts as others have said that need to be accessible years down the line, like financial records and the like, regardless of whether the company is still around.
You're assuming they actually care to distinguish. But real answer, barring a brief period where some users may get a cached version, they can likely just use the date of change to determine before and after if necessary.
reply