• 0 Posts
  • 41 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle

  • If you’re ok with some bulk, go for an nvme enclosure. I have a sabrent one with a 256 GB crucial gen 3 drive in it, it’s a slow cheap drive, still substantially better than any usb key and you can put one together for under $100 cad including a longer high speed cable.

    I just did a fresh install off of my usb key and wow, super slow compared to any time I’ve done off my enclosure






  • 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.





  • I gave it a fair shake after my team members were raving about it saving time last year, I tried a SFTP function and some Terraform modules and man both of them just didn’t work. it did however do a really solid job of explaining some data operation functions I wrote, which I was really happy to see. I do try to add a detail block to my functions and be explicit with typing where appropriate so that probably helped some but yeah, was actually impressed by that. For generation though, maybe it’s better now, but I still prefer to pull up the documentation as I spent more time debugging the crap it gave me than piecing together myself.

    I’d use a llm tool for interactive documentation and reverse engineering aids though, I personally think that’s where it shines, otherwise I’m not sold on the “gen ai will somehow fix all your problems” hype train.


  • 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.