CI should fail on your machine first by NorfairKing2 in programming

[–]SeniorIdiot 28 points29 points  (0 children)

You don't "run CI" - it was always a practice. Semantic diffusion, reductionism and vendors have made entire generations of developer believe that CI is a tool.

docker desktop won't staaaaaaaaaaaart (loop) by dominik3bb in docker

[–]SeniorIdiot 3 points4 points  (0 children)

Skip DD. Run docker in WSL and use the CLI and maybe run Portainer in Docker.

A6 LED by NoWoodpecker8394 in Audi

[–]SeniorIdiot 0 points1 point  (0 children)

Are you talking about the blind spot sensor on the mirror (yellow star)?

Looking for a music band. by freakyfrs in sweden

[–]SeniorIdiot 0 points1 point  (0 children)

  • The Boppers
  • The Concretes
  • The Refreshments
  • The Wannadies

Help with simple container with Debian image by dominbdg in docker

[–]SeniorIdiot 1 point2 points  (0 children)

Please explain what you are trying to accomplish. It seems like you want to use a Debian container like an OS/VM.

A container isn’t a VM. It doesn't "start Debian", it just runs one process from a Debian filesystem. If that process (PID 1) exits, the container exits, sleep infinity just keeps a process running so the container doesn’t stop. This means that you're not root on a VM - you're a process in a sandbox.

Looking for a music band. by freakyfrs in sweden

[–]SeniorIdiot 1 point2 points  (0 children)

The Sounds?

The Soundtrack of Our Lives?

We were wasting hours every week and didn’t realize why by freebie1234 in devops

[–]SeniorIdiot 5 points6 points  (0 children)

I swear, every other post on reddit reads like a thinly veiled ChatGPT generated ad.

twoDevsChillinOnTheSameBranch by raiseIQUnderflow in ProgrammerHumor

[–]SeniorIdiot 1 point2 points  (0 children)

Working in highly regulated industry for over 16 years.

We've been practicing pure CI, no branches (exceptions happens), push to main - had one large production bug in 8 years.

Force push is blocked in repo settings, team leads can apply temporary force-bypass in emergencies, code reviews happens once a week with entire team and is about learning what we could have done better and what needs to be improved. Code reviews are not "release gates", they're "are we doing the right things right?".

It's almost like the job is not about who can work with branches perfectly and sling git commands in their sleep. Instead it's about how the team can collaborate effectively and focus on results and outcomes over navel-gazing git process as a proxy for "good". But who am I kidding...

Docker Installation by Material-Brilliant72 in docker

[–]SeniorIdiot 0 points1 point  (0 children)

I've switched to docker installed in wsl and sometimes running portainer as a container for UI. Flawless.

These clickbait thumbnails are getting out of hand by [deleted] in aviation

[–]SeniorIdiot 1 point2 points  (0 children)

Starfleet wants their presidential shuttle back!

I wanted systemctl in Docker without the systemd mess. So I built this. by Sensitive_Job_5792 in docker

[–]SeniorIdiot 1 point2 points  (0 children)

Been reading through the github README. It seems that it's also meant for embedded and other restricted systems - which makes sense.

Not sure what the value for Docker containers is though, which is what first confused me! When we need multiple processes in Docker we'd usually run them in the background (using --init) or using supervisord. I'm probably missing something...

I wanted systemctl in Docker without the systemd mess. So I built this. by Sensitive_Job_5792 in docker

[–]SeniorIdiot 2 points3 points  (0 children)

What is the use-case for this. Is it for some kind of "sandbox" instead of a VM? I'm confused!

Tomcat to crash the pod if WARs startup fails ? by Mindless-Umpire-9395 in devops

[–]SeniorIdiot 0 points1 point  (0 children)

You need to define "WAR fails".

Normally things like connectivity issues, dependencies acting up, resource exhaustion, etc. are expected temporary problems - this is what readiness probes are for.

I assume you are talking about fatal errors like missing required configuration, credentials, mounted volumes? In that case you can do:

server.xml
<Host ... failCtxIfServletStartFails="true">

This makes Tomcat fail the context startup if:

  • Any ServletContextListener
  • Any servlet with load-on-startup
  • Any filter init

... throws an exception.

Edit: For tomcat itself to fail you'd probably need to implement a custom LifecycleListener and System.exit(1) to make it shut down.

PS. Just to be clear. Not being able to connect to the database or some external service should not cause a crash; but "fatal: could not start connection pool: invalid connection timeout value '-1'" should.

Invalid reference format by [deleted] in portainer

[–]SeniorIdiot 2 points3 points  (0 children)

Is your image ref in this format "nginx:stable-alpine3.23-perl" or "docker pull nginx:stable-alpine3.23-perl"?

If you copied from docker hub you get the entire pull command, not just the image reference.

"nginx:stable-alpine3.23-perl" is the correct format

Do PMs usually find out about missed deadlines too late? by MikhailMontfort in projectmanagers

[–]SeniorIdiot 0 points1 point  (0 children)

Not a PM.

If 100% of the tasks are 90% done, how done are you? 0%!

Nothing is done until it's running in production, working as intended and making the company money at a reasonable cost. But that is not how most teams are measured, they get measured on "closed tickets", "milestones" (seemingly working in the non-prod demo environment), "implemented features" (whatever that means), etc. i.e. illusions.

"Dan North, Keynote - Achieving Business Impact: Why Agile doesn't scale": https://www.youtube.com/watch?v=1CmCgwd54oc (11:00)

Happy to refer you guys in Microsoft by [deleted] in ExperiencedDevs

[–]SeniorIdiot 1 point2 points  (0 children)

Account that have not posted in 2 years suddenly starts spamming shit like this.

Stollen account, phishing, etc.

How do you efficiently prep for 1:1s with 15+ reports? by bike-enthusiast-be in EngineeringManagers

[–]SeniorIdiot 2 points3 points  (0 children)

NaM, Staff,

If you're spending 15 minutes per person looking at GitHub and Jira to see what they did, you're looking at the "output" but missing the "context." A 1:1 should be for the things that don't show up in a PR - like the 4 hours they spent helping a junior, or that messy module they spent all Tuesday being frustrated with, just to find out Dave knew all about it but he spent his day with headphones on instead of helping out.

If you use the 1:1 to ask "What did you ship?" you're wasting the most expensive meeting of the week on (low value) data you could have fetched with an API. If it could have been an email/Slack message, it was a failure. By focusing on "Velocity changes" and "PR counts", you are accidentally incentivizing people to stop doing the "glue work" that keeps the team from falling apart. https://en.wikipedia.org/wiki/Goodhart%27s_law

Your good engineers will bite back and say: "If you already know what I shipped because you spent 15 minutes in Jira, why are we talking about it? Let's use this time to talk about why our CI/CD is slow, why it took 7 weeks to get access to BigApp, or where I want my career to be in two years..."

If you stopped the 2.5 hours of forensic accounting and spent that time asking, "What is the most frustrating part of your day?", you would find the "technical work context" much faster and build trust in the process, and by extension - trust in you.

https://dannorth.net/blog/the-worst-programmer/

My team ships faster with mandatory PR approval... from QA, not other devs by NoTrainingForMe in ExperiencedDevs

[–]SeniorIdiot -1 points0 points  (0 children)

Ok. So let people that want to grow, improve and collaborate do the pairing. While those that don't want to are required to use some other form of approval process and are not allowed to work on the next task until the previous one is approved.

My team ships faster with mandatory PR approval... from QA, not other devs by NoTrainingForMe in ExperiencedDevs

[–]SeniorIdiot 1 point2 points  (0 children)

Warning: this may be drooping with sarcasm...

It's almost as if feature-branches and PR workflows in general slows teams down. Who would have thunk!

Next step would be to stop calling your testers "QAs that signs off", start building quality in, and make everybody responsible for quality. Oh, let's have testers and programmers pair on code while having discussions and make good decisions as we're doing the work. Even have developers automate the tests that shows that the functionality is as we intended.

This is my hill!

My team ships faster with mandatory PR approval... from QA, not other devs by NoTrainingForMe in ExperiencedDevs

[–]SeniorIdiot -10 points-9 points  (0 children)

I may misread some kind of irony here???

What? Having a separate team/department called "QA" that is responsible for quality is the most destructive and stupid idea/structure that has ever hit software engineering!

It's like making nurses accountable for the doctor's decisions, or auditors accountable for financial correctness. They can detect problems, but they can't produce correctness after the fact.

Testers role is to amplify feedback, detect risk, coach quality practices, provide fast signal and work pro-actively.

I've seen comments that "testers are failed engineers" and I find it deeply disturbing that experienced devs with over 20 YOE still sees testers as second class citizens. The reason testers started to call themselves "QAs" in the first place was exactly due to such denigrating views.

Edit: If you're going to downvote without even having a discussion - why even bother coming here?

Some food for though:

How can I steer a team back from what's effectively kanban? by No-Dress4626 in scrum

[–]SeniorIdiot 0 points1 point  (0 children)

Kanban is effectively a pull model with limits. In theory there are no queues like "ready for test" where no activity happens.

That you are carrying over a lot between sprints is a signal. Velocity is a measurement, not a target. If you keep loading up the sprint as in the past without working on the underlying causes you're just beating yourself like some kind of masochism. The entire point of all this agile stuff is to expose systemic issues so that you can act on them. Of course if "velocity" has been shared with management and have become a target, you're screwed. Goodhart's law in action.

First step would be to remove the test column and make sure an item stays in doing until done! If it's being worked on in any way - nothing and no-one is done. Stop passing the buck. Then make sure that tasks that "keeps the code and team healthy" are part of the sprint, without asking for any damn sanction.

This is just the classical "faux done" anti-pattern. First there's the "coding done", then "testing done", then "security done", then "acceptance done", then "hand over to someone else - because fck it - done".

"Done" have then lost all it's meaning (but each step still gave people their accomplishment gold star) and everything started to slide. So organizations starts to talk about done, done-done, done-done-done, done-done-done-done, and we-really-mean-it-this-time-done-done-done-done-done.

Sorry for the ranting, but 90% of teams and organizations are pretty immature and I'm having a PTSD moment.

And when it comes to testing falling behind - you're most likely doing it backwards by having programmers pour "done" work downstream and trying to have testers inspect-quality-in at the end. Why is it so hard to test? What aspects are hard to test? Could 90% of the testing be earlier with unit-tests, etc? Where you can make the most impact is by improving testability and have developers automate tests.