cjvirtucio

my favorite tool; makes writing a bash fun for me.

you could also just write as if you're writing go:

function main {

  if ! failing_cmd; then
    log "this fails!"
    return 1
  fi

  log "this won't log"

}

main

I only mention this because there are folks who don't like set -e.

reddit and youtube were my last remaining social platforms. quit reddit because of the API changes. might be quitting youtube, as well, because of the ads. and then there'll be nothing left for me to spend time on except code and family.

most fun I've had with a programming language in years

good ole find, grep, sed, and jq.

the main thing that allows me to be productive with "only" vim is, funnily enough, things outside vim: bash knowledge. search, for instance, I can usually do in flexible ways with a pipeline of commands.

I wouldn't mind this, honestly. a game can be solid even on an old engine. just look at how long the Monster Hunter series had been on their old engine before overhauling with World.

it's so much easier to glue tools together with it. I'd end up writing more code if I had used python's subprocess package or ruby's IO package. as long as I don't need a complex data structure of some sort.

huh. TIL, that's pretty cool. guess I know what I'm doing next weekend..

would've liked something like this on hugo

>Knowing that I had two offers, and that I had gone through a very long process with them and having received an offer, I knew that I was a candidate they'd like to hire. This is the perfect time to get that extra worth, as you hold a lot of the chips, especially with two offers.

This has always been really hard for me to do, particularly if I actually am happy with the offer. It could be imposter syndrome, where I often feel like I don't "deserve" it.

I've worked with .NET in the past few years and I've been pretty happy with it. The syntactic sugar is great, and it seems like we get interesting new features every release. My favorite from .NET 6.0 has to be the integration of dotnet-format as a subcommand. I regularly use vim so being able to format code without opening an IDE has been really helpful.

Ansible has a linter. We do use it on our playbooks (locally and in CI). There's also a framework for testing and linting ansible plugins (ansible-test IIRC), though that's been a little painful for us to setup.

That said, we do have a lot of helper scripts that we use in our day-to-day (local development). They're not "large bash scripts", but they're small enough that we don't really need a proper programming language. Some degree of code quality with style guides and shellcheck does help.

I find tests more helpful when the implementation is stable. It's a little tedious to re-write test cases as unknowns come up.

and on the off-chance that `stuff` must be a space-separated string for w/e reason:

  IFS=' ' read -ra routes <<<"${stuff}"
  for route in "${routes[@]}"; do
    curl localhost:8080/"$route"
  done

I'm annoyed at how sed has --regexp-extended, while grep has `--extended-regexp`. I'm sure there's a reason for it, but it always makes me stop and think which command has which flag.

Some companies only support OSX or Windows workstations, in which case WSL helps (for the latter scenario).

This approach reminds me of the DevOps practice of breaking down information silos: make everyone learn a little bit of everything so that no one becomes a risk.

It's gotten to a point where if I run into an issue, my first instinct is to go to the source code instead of the docs.

There's a tangible benefit to programming, e.g. I just automated this process and now it runs daily and I don't have to worry about it anymore for the 99% case.

I can't get that with a rubik's cube.

pylint irritates me a bit for this. I already created an abstraction, and I'm using the abstraction in a few places, but pylint doesn't like that and says it's duplicate code.

unipdf for golang is another example.

I agree with this.. I've personally been more effective in an async communication type of approach. Communication over email, slack messages, ticket comments.. just leave a comment on my ticket, give me time to ponder on it, then I'll respond. If there's anything mission critical that really requires everyone to sit down in a room together, then we can schedule a meeting.

I accept that not everyone's like me, though.

I typically write bash wrappers in situations like that. You could also write in a real programming language that shells out to the CLI tool if it gets too complicated.. even better if there's a library that does away with the need of shelling out.

Fully automated a process that I had zero domain knowledge on.

I have difficulty maintaining a stance in the OOP vs. FP debate. Like, all I see in my day-to-day is OOP, so I know what good, production-ready OOP looks like, but I've never an equivalent for FP. Would be nice to see a before/after article, i.e. an OOP app refactored into FP, talking about why the latter is better.

She could literally execute the piledriver with a flick of a finger!

What happens when one is working on something that is neither of the two things in your last sentence?

Agreed.. there's ways to have a "pristine" environment on the host machine, anyway. Our team uses ansible.

Inbox was good.

And then they killed it for no reason.