3 ms·

Pretty obvious why if you use the software. I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all d

Pretty obvious why if you use the software. I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all dev focused software. That's who pays for all your tools to have free versions. People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying to use aren't worth any money to companies.

NitpickLawyer 1y ago
> People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying ??? Mash 'em, boil 'em, put 'em in git, next to your code?
mixologist 1y ago
My experience is the opposite. Teams that are knowledgeable jury rig their own custom solutions without all the enterprise cruft. They make solutions that fix their problem and they do it faster than the teams who use bloated enterprise solutions. I am tired of seeing over engineered enterprise solutions that that are implemented and never used because they can’t be integrated into the dev workflow easily. Simple bash script that does the task it was designed to do beats any enterprise crap.
- bravetraveler 1y ago
  The wisdom of pipes! I'd share these workflows the exact same way we share others [ie: BASH, Ansible]: Git. Needs nothing more than a directory, though an SSH daemon is quite nice. Those of us who can survive without desperate monetization plays are worth quite a lot, actually. They say 'jury rig', we say 'engineer'.
- array_key_first 1y ago
  The main problem with enterprise crap is portability. It only runs under very specific circumstances. Bash and Perl scripts run, truly, everywhere - so you get real collaboration. I can share it with anyone on my team and they can use it.
  - 20after4 1y ago
    Well written bash will run anywhere. Amateur bash will only run on the version of Mac OS it was written on, and even then only after the correct collection of random homebrew packages installed has been installed.
    - array_key_first 1y ago
      I agree, which is why I think most bash scripts should actually be Perl scripts. There, I said it.
jbverschoor 1y ago
You put them in your repo or file server. No need to have all these accounts and potentially leaks/attacks Git is pretty good at sharing you know
coldtea 1y ago
>I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all dev focused software. Complacent corporate teams. Agile teams need to simplify their workflows, and know that a Makefile can be better than some closed down, Cloud-first tool. >That's who pays for all your tools to have free versions Nah, we have free versions for stuff without enterprise editions too. >People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying It's that "no-one else" that doesn't bring value.
motorest 1y ago
> (...) teams need ways to share their complex workflows (...) Apps like Postman are the wrong tool for this purpose. If you want to share workflows, let alone complex workflows, any automated test suite is far better suited for this purpose. We are in the age of LLMs and coding agents, which make BDD-style test frameworks even more relevant, as they allow developers to implement the workflows, verify they work, and leave behind an enforceable and verifiable human-readable description of those workflows.

NitpickLawyer 1y ago

> People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying ??? Mash 'em, boil 'em, put 'em in git, next to your code?

mixologist 1y ago

My experience is the opposite. Teams that are knowledgeable jury rig their own custom solutions without all the enterprise cruft. They make solutions that fix their problem and they do it faster than the teams who use bloated enterprise solutions. I am tired of seeing over engineered enterprise solutions that that are implemented and never used because they can’t be integrated into the dev workflow easily. Simple bash script that does the task it was designed to do beats any enterprise crap.

bravetraveler 1y ago
The wisdom of pipes! I'd share these workflows the exact same way we share others [ie: BASH, Ansible]: Git. Needs nothing more than a directory, though an SSH daemon is quite nice. Those of us who can survive without desperate monetization plays are worth quite a lot, actually. They say 'jury rig', we say 'engineer'.
array_key_first 1y ago
The main problem with enterprise crap is portability. It only runs under very specific circumstances. Bash and Perl scripts run, truly, everywhere - so you get real collaboration. I can share it with anyone on my team and they can use it.
- 20after4 1y ago
  Well written bash will run anywhere. Amateur bash will only run on the version of Mac OS it was written on, and even then only after the correct collection of random homebrew packages installed has been installed.
  - array_key_first 1y ago
    I agree, which is why I think most bash scripts should actually be Perl scripts. There, I said it.

jbverschoor 1y ago

You put them in your repo or file server. No need to have all these accounts and potentially leaks/attacks Git is pretty good at sharing you know

coldtea 1y ago

>I get the whining, but teams need ways to share their complex workflows, and teams are where the money is for all dev focused software. Complacent corporate teams. Agile teams need to simplify their workflows, and know that a Makefile can be better than some closed down, Cloud-first tool. >That's who pays for all your tools to have free versions Nah, we have free versions for stuff without enterprise editions too. >People who use make and curl to jury rig some unshareable solution together that no-one else in their company would even bother trying It's that "no-one else" that doesn't bring value.

motorest 1y ago

> (...) teams need ways to share their complex workflows (...) Apps like Postman are the wrong tool for this purpose. If you want to share workflows, let alone complex workflows, any automated test suite is far better suited for this purpose. We are in the age of LLMs and coding agents, which make BDD-style test frameworks even more relevant, as they allow developers to implement the workflows, verify they work, and leave behind an enforceable and verifiable human-readable description of those workflows.