• 0 Posts
  • 28 Comments
Joined 1 year ago
cake
Cake day: June 22nd, 2023

help-circle



  • I’m gonna be completely honest. I don’t truly get all the inner working of git. I’m a senior DevOps Engineer and been using git for a decade, but is git is simular to sed or awk for me. I know how to do what I want really well but when shit goes wrong, I’m flying by the seat of my pants.

    A lot of times, I just know what to do to fix things because it’s rote memory with substitutions. But if you needed me to explain upstreams and rebases in actual detail, I’d be in trouble. But it rarely becomes an actual problem to the level where I’ll dedicate time to learning all the advanced stuff.

    That said, I’ve learnt that most senior people also just pretend they get it all but instead are just relying on rote memorization and basic concepts. Anyone else here in the same camp of being a fraud with git?


  • The company reportedly told employees they can apply for other jobs within the company, though some doubt they’re qualified for other Apple roles in the city, and most don’t plan to move.

    Sounds like it’s QA people. Which sucks extra hard cause that’s a much harder field to get another job in. If they were software engineers, the world would be their oysters. I bet a lot of people will make the move and it’s quite shitty and cynical from apple to move a team that doesn’t have a lot of options.

    If they tried to move an engineering team to texas, they know they’d get told to get fucked






  • Here’s a link I found that might be good if you are interested in more:

    https://cloudnativenow.com/topics/ephemeral-idempotent-and-immutable-infrastructure/

    https://guymorton.medium.com/persistent-and-ephemeral-infrastructure-as-code-in-aws-42b33939dcf1

    There are different levels of effemeriality. The simplest example I use daily would be an autoscaling group in AWS. Especially if you use Spot Instances to save money, thi gs may scale in and out whenever.

    So if a development team creates a new autoscaling group and I need to get into an instance to test something, unless I add stuff to their IaC, I’m stuck with their configuration. I need to assume that every time I ssh into one of those instances, it’s a brand new instance. But it’d be a big challenge for me to go to their repo and make a PR to alias a command whenever an instance in that resource is created

    Stuff can be even more temporary if it’s something like an ECS task which creates a container with a read only filesystem only when a task is needed to be done. But I don’t want to get too deep in the weeds (or deeper than I already have)

    terraform workspace will at least stick around for a while so you might be in and out of the same system multiple times.


  • {vi} = 2 {vim} = 3 {v=vim} = 5

    I’d need to run vi at least 5 times to have a net gain in saving keystrokes. I’m typically in effemerial systems created by the users of our env, so rarely am I going to gain those strokes back

    But also, why am I trying to apply logic to this? I’ll often cat a file before editing it. This shit is just illogical idiosyncrasies I’ve picked up over the years. I’m probably creating posthoc justifications for insane things I do cause it’s hard to override muscle memory


  • I’ll have to check tomarrow if RHEL and UBI do this.

    Did some quick googling and looks like cent has that alias by default but doesn’t do it when root. Which would explain why I do get inconsistent results with vi. I never thought about it in detail besides just knowing that there are some visual changes. Thanks for the info, I’ll be noticing this now that I know!



  • I’m in DevOps so I’m in a lot of effemerial systems so in practice, I will run into systems where profile hasn’t been set up. Tho I do like the idea of making sure all systems properly have that aliased cause it’d be serial killer vibes to spend hours of time to make sure that I can save a keystroke.

    Tho it’d never make it through PR. Also, wild require explaining to my coworkers that I do this







  • Been waiting a few years to replace my iPhone 12 Pro but each year has not been too compelling it’s own. I’m already 95% sure I’ll be getting whatever phone they announce this year.

    Tho if they do upgrade to USB-C (which I assume they will), I might wait for some durability tests on the port to come out. I have a shit ton of lightning connectors and am used to it, so not switching isn’t much of a problem but could be worth not switching to USB-C if it’s more likely to break than the tried and true king of durability

    [clarification] I’m saying the port is the king of durability, not the cable/connector/plug