Skyzyx

@Skyzyx@lemmy.world

• ⁨Comment⁩ on ⁨Sony Steals Customers' Purchased Content - Piracy is COMPLETELY JUSTIFIED!⁩ ⁨⁨11⁩ ⁨months⁩ ago⁩:

  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.

• ⁨Comment⁩ on ⁨How do you get your team to write tests?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I think it depends. If you have to refactor in order to test, you probably built it poorly the first time around.

• ⁨Comment⁩ on ⁨How do you get your team to write tests?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Sounds like a bunch of junior engineers with senior job titles.

  “Senior” is the new mid-level.

• ⁨Comment⁩ on ⁨What is the best file format for configuration file?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Whatever. Comments are helpful, which makes pure JSON a poor choice. JSON5 or JSON-C are better, but linting and static analysis are important to every form of code, so make sure that what you use for that will understand your syntax.

  My current preference is generally TOML, but I’ve started dabbling with custom HCL2 DSLs. (I write a lot of Go and Terraform.)

• ⁨Comment⁩ on ⁨How much does naming consistency matter?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I build software that is used by nearly all engineers in our company. We own hundreds of web applications and websites. We’ve grown by acquisition of smaller companies, and we have an extremely heterogenous environment.

  25 years ago, I started my career as a web designer. Today, I’m a Principal Cloud and Platform Engineer. Still to this day, I regularly leverage lessons when building tech that I learned from the world of UX.

  “Design is not how it looks. Design is how it works.” — Steve Jobs

  Naming consistency helps to reduce the mental friction that people have when learning how something works. For example, one my projects is a suite of Terraform modules that are designed as building blocks which cover all of the fundamental pieces of any app’s stack. We have designed these 20-ish modules to work well standalone, as well as when used together. Certain patterns are the same across the board.

  1. We strongly favor dependency injection, and limit the use of ternary statements. In the world of Terraform, this is via variables or a .tfvars file. Everyone knows that this is how it works, so it reduces the mental friction when adopting a new/additional module.

  2. Variable names which do the same thing are named identically across all modules. Their descriptions are identical. For example, tags = [k:v] works exactly the same way across all modules, and people don’t have to think about it.

  3. Modules have a naming pattern. Among other things, they begin with the name of the service that the module talks to. (If we find that we’re talking to multiple services, we need to break the module down into smaller chunks.) So aws- or newrelic- or datadog- or github- or pagerduty- are all examples.

  This overall “design” has not only helped reduce mental friction and made the modules easier to understand and use, but it also makes them easier to manage across hundreds of repositories supporting hundreds of apps. Collaboration, cooperation, and communication are all improved as a result. And if something is difficult to understand, then it means that we screwed up. We need to do a better job listening to the app-engineering teams and SREs who support them to streamline and clarify as much as possible.

  “Customers” come in all sorts of shapes and forms.