FML, I’ve had to try to color matching by eye before between different screens by the same manufacturer.
For whatever reason I wasn’t provided with any calibration tools. I had some vague software tools to try and get them to align.
I spent like 8 hours trying to match these for the corporate brand colors, while still looking decent for everything else.
Shit is near impossible. If the manufacturer couldn’t do it, how am I supposed to?! And with awful interfaces and no concrete way of measuring.
Like, I was taking pictures of the screens, then trying to figure out offsets and how they might relate to gamma triangles.
Client was appreciative of my (and fellow techs) efforts, but ultimately wasn’t happy, and it looked shit.
That was awkward as fuck.
I’ve never done anything close to the color calibration work, in part because my vision is color-deficient by default, so any tools or processes relying on my own visual acuity isn’t going to come out right.
However, I was under the impression that there existed external tools that basically did exactly what you were trying: Taking actual images of the screen in a controlled way and comparing it to physical (or at least a known-good digital) copy of that same image and outputting the “right” profile.
Is that made-up bullshit someone fed me and I never cared to verify it?
Yeh, you get a special camera and some software. Whether the camera looks at the whole screen, or it is something you put directly against it depends on the system.
If you are just doing relative calibration (IE making screens look the same without caring about the actual calibration) I think they can work with just a DSLR.
Cargo fetches dependencies, runs a variety of build tasks, can build a typical Rust project with little or no build scripting, and is configured with a straightforward TOML file. It’s not at all like a hand-written shell script. It’s also much more pleasant to use than any other build system I’ve seen, including shell scripts.
I've been using Gearset for Salesforce CI/CD for a while and it's pretty simple to get up and running and it just kind of works. I'm looking into integrating it with Azure for our .net stack but not sure how smoothly that will go.
If you’re using a GUI, that means whatever you’re doing you’re not doing a lot of it, since you don’t need to automate it. I would expect a world-class enterprise engineer to be able to automate most tasks, and from that they would be very comfortable with the command line.
Can you do everything with a GUI that you can on a command line? Yeah probably, if the developer is at all the features properly. Can you automate it easily? No not at all. So the more you do something the more you tend to want to deal with the vocabulary of the command line because it’s more expressive and allows for automation.
Depends on what system you’re running, and especially what task you’re doing. Trying to operate firewall rules via CLI is an exercise in self-inflicted pain, as is trying to set a complex cron schedule without a handy calculator.
Documentation too. Frontends change all the time, but CLI tools usually don’t, so you can usually rely on old documentation. But have you ever tried googling how to do something in MS office, found and article from half a year ago and found that none of the things it mentions exist anymore? It’s ridiculous how much time people waste trying to figure out stuff multiple times because it changes so much.
CLI debuggers can’t hold a candle to the Visual Studio debugger. This is generally not something you automate, and I haven’t met many engineers that know gdb well. But pretty much anyone can use VS debugger.
Similar to how vscode uses Ctrl+shift+arrows for multi line editing but for some reason on my person computer that is hot keyed to flip the screen upside down.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.