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