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.
The more and more I use CICD tools, the more I see value in scripting out my deployment with shell scripts and Dockerfiles that can be run anywhere, to include within a CICD tool.
This way, the CICD tool is merely a launch point for the aforementioned deployment scripts, and its only other responsibility is injecting deployment tokens and credentials into the scripts as necessary.
Anyone else in the same boat as me?
I’d be curious to hear about projects where my approach would not work, if anyone is willing to share!
Edit: In no way does my approach to deployment reduce my appreciation for the efforts required to make a CICD pipeline happen. I’m just saying that in my experience, I don’t find most CICD platforms’ features to be necessary.
All the build logic is coded in python scripts, the jenkins file only defines the stage (with branch restrictions) and calls the respective script function.
This means it works on all machines and if we need to move away from jenkins integration with a new ci platform would require minimal effort.
I’ve found Docker helpful when I want to use it to build binaries or use CLI tools that may not be available directly on the CICD platform. Also, Docker makes it easier to run the same code on MacOS that I ended up running on a Linux CICD server.
What would you consider to be overuse of containers?
Most of those things mentioned aren’t bona fide needs for me. Once a developer is deploying their project, they’re watching it go through the pipeline so they can quickly respond to issues and validate that everything in production looks good before they switch contexts to something else.
I see what you’re saying though, depending on what exactly is being deployed, the policies of your organization, and maybe expectations that developers are working in another context once they kick off a deployment, it could be necessary to have alerting like that. In that case it may be wise to flex some features of your CICD platform (or build a more robust script for deployment that can handle error alerting, which may or may not be worth it).
I come from game dev. We do lots of checks on the data that all kinds of people can screw up. So it’s important these situations are handled automatically with an email to the responsible person. A simple change can break the game, or someone might commit an uncompressed texture so the memory usage jumps up.
You’re not advocating against CI like the meme seems to be, but rather for CI builds to be runnable on human’s machines and the results should be same/similar as in when running w/in the CI system. Which is what CI folks want anyway.
I don’t think there is a single right or wrong answer but to play devils advocate making your CI tooling lightweight orchestration for your scripts that do the majority of the work means you lose the advantages of being able to easily add in third party tools that you want to integrate with your pipeline (quality, security, testing, reporting, auditing, artefact management, alerting, etc). It becomes more complex the more pipelines you are creating while maintaining a consistent set of tooling integrations.
I know this is a meme, but just in case someone doesn’t actually know. CI saves literally thousands upon thousands of dev hours a year, even for small teams.
And a lot of users' frustration, especially on more niche platforms (Linux, ARM, etc.) - things look much better on release when the code have been regularly compiled and, hopefully tested, on all platforms, not just the one the lead developer uses.
I can’t even imagine not having a ci pipeline anymore. Having more than a single production architecture target complete with test sets, Security audits, linters, multiple languages, multiple hour builds per platform… hundreds to thousands of developers… It’s just not possible to even try to make software at scale without it.
If you fuck up the setup and deploy to multiple environments at once with each one set to rebuild an image/program things can get long. You really have to fuck it though.
As annoying as it is when someone else breaks the CI pipeline on me, it is utterly invaluable for keeping the vast majority of commits from being able to break other people (and from you breaking others). I can’t imagine not having some form of CI to preventing merging bad code.
Hah, or my current one. Before we had CI you just directly committed to master (on SVN). It was incredible how unstable our build was. It broke basically everyday. Then one of the senior back end guys got promoted to architect and revamped the whole thing. Probably saved the company tens of millions dollars in man hours, at the very least.
Even better is when you restrict merges to trunk/main/master/develop (or whatever you call it) to only happen from the CI bot *after all tests (including builds for all supported platforms) pass. Nobody else breaks the CI pipiline, because breaking changes just don’t merge. The CI pipeline can test itself!
Ah, good 'ol Jenkins. It’s on my list of software I never want to use again, twice.
One feature was really sweet though: being able to edit the Jenkinsfile script inline and run it. On the other hand, that encouraged the wild cowboy lands. Contrasted to GitHub Actions, you get to see how many commits it took to get right 🙃
What’s wrong with Jenkins? Works pretty great for automated scripts that need to run on a schedule, but I imagine you and this post specifically mean in reference to CI/CD
I work for a very large company which uses Jenkins for CI/CD and it’s an absolute nightmare. Granted, some of these issues may be related to how my company has it setup. I’m not in DevOps so I wouldn’t know. But these are my complaints:
Can have incredibly long queue times in some cases. It takes forever to spin up additional build agents to meet demand. In one case we actually had to abort a deploy because Jenkins wasn’t spinning up more build agents, and our queue times were going to put us outside of our 3 HOUR maintenance window.
Non-standard format for pipeline configuration files. It could just be JSON or YAML, but noooo, I have to learn something completely different that won’t transfer to other products.
Dated and overly complicated UI with multiple UX issues. I can view the logs in a modal from the build page, but I can’t copy from them? Fuck off Jenkins.
I’m actively pushing my team to transition to GitHub actions, because it’s just better in every single way.
Ah man, yeah I use it for a much more constrained and very narrow use case. We only use GitHub actions for CI/CD, it can be clunky itself in some aspects but otherwise works great.
And if you have a large company and many teams, you think actions will help? (Aside from the UI issues you mention). Rebuilding the Jenkins from scratch now would probably get rid of most of your problems, but in a year is gonna be a mess. It’s similar to how it’s going to go with and CI.
Also, a good DevOps person or team will keep the Devs happy (or at least, not very unhappy) with any tool, a bad one will suck anyhow.
The poorly documented pipeline scripting was always a nightmare for me, plus there’s two different types (declarative vs scripted) and so you have to be extra careful pulling examples from the Internet.
The build agent issue is 100% on your company not providing enough agents though. These days you can spin up agents as containers on k8s as needed.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.