Skyzyx
My strongest languages, in no particular order, are Go, Python, JavaScript, and modern PHP (with types and all that jazz).
I’ve decided to go with JavaScript this year because over the last 15 years, they’ve been working on JavaScript like it’s the cure for cancer. They’ve added so much syntactic sugar to JavaScript in recent years, that I can develop solutions in fewer lines of code.
That said, for day one, I did separate implementations in JavaScript and Go. With Go, I leveraged the built-in support for testing, benchmarking, and profiling to look at the flame graph and figure out where I could optimize performance.
I’ve been wanting to learn both Rust and server-side Swift. I figure that during my time off over the holidays, I can practice porting my JavaScript solutions over to those other languages.
Copyright is literally the definition of “who has the rights to determine how copies are made.” If you were to believe most people who publish content on YouTube, you might think that copyright means authorship, but it does not.
When you purchase a movie on Blu-ray, you don’t own the film. You own a piece of plastic which represents a license to watch the film. But you can’t turn around, make copies, and start selling those copies without violating The film studios “right to determine how copies are made.“
The only difference between a physical Blu-ray (license) and a digital license is that digital license is revocable. It’s not fair. It isn’t just. But it’s literally part of the contract that you agreed to.
There’s a separate discussion to be had around “fair use.” Backing up stuff that you have paid money for does fall into “fair use,“ unless third-party encryption is involved. Because it is against the law to circumvent encryption. (Unless, of course, you’re the FBI.)
This is the only characteristic that separates ripping CDs from ripping DVDs — CDs missed the boat on encryption.
I’m not necessarily arguing for or against anything here other than to simply explain how it currently works (in the US, at least). There’s a separate discussion to be had about perpetual versus revocable licenses after money has been exchanged. Beyond that, there’s a discussion to be about how to protect the intellectual property of the things that you spent millions of dollars creating; and how that fares with the consumers of said intellectual property.
These latter discussions are far more nuanced than most Internet commenters are qualified to decide.
If you weren’t already, be very careful about which extensions you are installing.
That’s literally always true. For everything. Don’t install it if you don’t understand where it came from.
I have mixed feelings. I spent 4 years working at AWS, was an original member of the SDK/CLI team, and I regularly work across the spectrum of AWS services on a daily basis. Is it worth the effort to get a (virtual) piece of paper with my name on it? Maybe, maybe not.
But if you lack the experience/reputation and are trying to build it, I think it could be useful. But it only matters if you’re actually doing the things that you get certified on. Because learning for real is more important than a (virtual) piece of paper with your name on it.
IIRC, GitHub.com and GitHub Enterprise support using SSH for signing. I think that whatever is used should leverage asymmetric/public-key cryptography.
Passkeys maybe?
- Based in the US.
- Salary employee (overtime doesn’t apply).
- We embrace “shift-left” methodology, which means that we own our stack, soup-to-nuts.
- It makes zero sense for us to build an application, then toss it over the fence to another team that knows nothing about it.
- We partner with specialist teams for any skill that we don’t have on the team. While many of us have Dev and also Ops skills, we partner (for example) with our SRE team on certain matters. We still own the work, but we “sub-contract” it out to our SRE team.
- We devs are on-call, and the SRE team that supports us is also on-call. Both teams get paged for any production incident. Our team is ultimately on-the-hook, but SREs are there to have our backs.
- It empowers/enforces us to make sure that we don’t ship crap. And if we do, we get paged.
- We think about SLIs, SLOs, error budgets, and work to identify trouble spots in the application.
Based on the way you wrote your questions, I sense that your situation is completely different from mine. But we work hard to eliminate silos, eliminate fence-tossing, and partner together with experts to ensure that what we ship is of a high quality so that we don’t get paged in the middle of the night. The better we do our daytime jobs, the more we can sleep in the nighttime.
I think that instead of “forcing tests”, you should instead focus on “proving quality.” You think that works the way you thought? Cool. How do you know? What if they were to use 128 NUL bytes? Would it still do the right thing? Cool. How do you know?
Ensuring quality is a larger concept than simply writing tests, but writing tests is definitely part of it. I think if you aim higher and teach the provability of quality, then the better engineers will self-select by starting to write tests.
“If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.” — Antoine de Saint-Exupery
Additionally, if you’re one person against the world, you’re going to have a tough time. Build alliances. Partner with people who will reinforce the message. If you are the only one telling them something they don’t like, they will shun you for it. But if you partner with allies who all have the same message, people are more likely to start to listen. It starts to become a community.
And if all else fails, prove the value of tests by going first. You can’t force anyone to do anything. But you can start doing this yourself. At some point, if code gets called into question, you can look at the tests together to see what’s covered and how that thing is supposed to work. It’s all part of letting the robots do what the robots are good at, which frees you up to do the things that you’re good at.
Sounds like a bunch of junior engineers with senior job titles.
“Senior” is the new mid-level.