• 1 Post
  • 85 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle




  • I was originally going to to go the docker route but honestly just ended up going the binary route and leaving it using sqlite as it’s good enough for now. It’s pretty well documented and a chunk of the prereqs I already had, like the git user creation.

    Did have SSH auth issues though, probably becauae I didn’t fully cleanup after uninstalling gitlab (oops), had them in parallel for a bit to migrate the repos, gitlab had it trying to use gitlab-shell which didn’t exist anymore. Probably a better/proper solution but what worked was changing the git user’s home directory back to /home/git as gitlab had it using a gitlab config directory. I welcome anyone giving me a better/cleaner solution for this, on my to do list to do some more cleanup.




  • Heck, there are already ISO language standards, and there’s ISO Software Lifecycle standards, it’s absolutely not a leap to move into standards adhering processes. It’s not like there’s no desire to do it either, code standards alone, how many times have you had discussions about style guides and coding standards company wide? It makes things more consistent and easier for different developers to maintain.

    Semi related, I see a lot of non-iso standard SQL that’s a pain if you do migrations or refactors, often even just sucks to read through (old school oracle joins look really strange and aren’t clear compared to iso standard joins). I really wish people would adhere to the standards as much as possible.


  • I realised you meant this over lunch, I’m a mech eng who changed disciplines into software (data and systems mainly) over my career, I 100% feel you, I have seen enough colleagues do things that wouldn’t fly in other disciplines, it’s definitely put me off a number of times. I’m personally for rubber stamping by a PEng and the responsibility that comes with that. There’s enough regulatory and ethical considerations just in data usage that warrants an engineering review, systems designed for compliance should be stamped too.

    Really bothers me sometimes how wildwest things are.


  • Edit: see my response, realised the comment was about engineering accountability which I 100% agree with, leaving my original post untouched aside from a typo that’s annoying me.

    I respectfully disagree coming from a reliability POV, you won’t address culture or processes that enable a person to make a mistake. With the exception of malice or negligence, no one does something like this in a vacuum; insufficient or incorrect training, unreasonable pressure, poorly designed processes, a culture that enables actions that lead to failure.

    Example I recall from when I worked manufacturing, operator runs a piece of equipment that joins pieces together in manual rather than automatic, failed to return it to a ready flag and caused a line stop. Yeah, operator did something outside of process and caused an issue, clear cut right? Send them home? That was a symptom, not a cause, the operator ran in manual because the auto cycle time was borderline causing linestops, especially on the material being run. The operator was also using manual as there were some location sensors that had issues with that material and there was incoming quality issues, so running manually, while not standard procedure, was a work around to handle processing issues, we also found that culturally, a lot of the operators did not trust the auto cycles and would often override. The operator was unlucky, if we just put all the “accountability” on them we’d never have started projects to improve reliability at that location and change the automation to flick over that flag the operator forgot about if conditions were met regardless.

    Accountability is important, but it needs to be applied where appropriate, if someone is being negligent or malicious, yeah there’s consequences, but it’s limiting to focus on that only. You can implement what you suggest that the devs get accountability for any failure so they’re “empowered”, but if your culture doesn’t enable them to say no or make them feel comfortable to do so, you’re not doing anything that will actually prevent an issue in the future.

    Besides, I’d almost consider it a PPE control and those are on the bottom of the controls hierarchy with administrative just above it, yes I’m applying oh&s to software because risk is risk conceptually, automated tests, multi phase approvals etc. All of those are better controls than relying on a single developer saying no.


  • I just really like KDE, been between that and XFCE for years. Ubuntu’s version of gnome when they went to that side bar layout that looks like it’s meant for tablets turned me off of trying it again (though probably be great on a tablet). KDE’s super customisable too, totally done a faux osx look for my laptop and use more or less stock KDE on my shop computer. I didn’t mind older gnome though, isn’t that what cinnamon or mate are meant to feel like?




  • A lot of industry does use grey water or untreated water for cooling as it’s substantially cheaper to filter it and add chemicals to it yourself. What’s even cheaper is to have a cooling tower and reuse your water, in the volumes it’s used at industrial scales it’s really expensive to just dump down the drain (which you also get charged for), when I worked as a maintenance engineer I recall saving something like 1m cad minimum a year by changing the fill level in our cooling tower as it would drop to a level where it’d trigger city water backups to top up the levels to avoid running dry, and that was a single processing line.






  • I did a student project for server room HVAC fans being annoying back in uni, targeted reduction in those annoying or peak frequencies was a totally acceptable outcome as to not disturb operators (was for a simulated patient in the attached hospital). I’m not an acoustic engineer, so obviously take what I’m saying with a grain of salt (did do a lot of safety and risk work though), making things less annoying is perfectly valid if they’re not already harmful to your hearing in the first place.

    What’s cool to me is that it’s just printable, so in theory super accessible and anyone could iterate on it if they desired (assuming it gets open sourced)