3 ms·

I have to say I really disagree with the thought that one should bake a whole bunch of custom functionality into their ide. My company did this. A special, cu

I have to say I really disagree with the thought that one should bake a whole bunch of custom functionality into their ide. My company did this. A special, custom version of eclipse was required to even build or deploy their applications. What happened? It was abandoned, and since that build / deploy functionality never existed as independent utilities it was completely lost. I had to piece together how to build my application by pulling build files off of our old ass legacy cicd server and even that process is pretty horribly broken. As things stand, the legacy app I'm tasked with keeping alive is held together with bailing wire and chewing gum and almost all requests for new features are turned down. This is not a unique problem to my team, it's org wide. Tons of legacy apps are limping along because 'the knowledge' of how to do things properly was bundled up into eclipse plugins we no longer have access to.

maccard 5y ago
That's no different to requiring an arcane incantation of shell scripts that call maven, git, curl, docker, , etc. The advantage of having it built into IDEs or CI servers (and by built in I mean TeamCity/Jenkins providing it, not a self inflicted third party plugin) is that you can build around these steps. Imagine if all CI servers supported merge previews or mergebots - that workflow gets unlocked for everyone!
- wing-_-nuts 5y ago
  at least with the shell scripts I can quickly see what it does. I much prefer the unix philosophy of small bits of code that do one thing, and do it well. Such things can be combined to make bigger things. Want to make a plugin out of those individual scripts? Knock yourself out! Meanwhile, a decade from now, some engineer can actually reconstruct if needed. Much better than a 'binary blob' plugin that gets abandoned.
zcw100 5y ago
I used to do this, on and off, with vim. Hey customize this, and that, and add some special key bindings and plugins. Then you go to ssh somewhere and you're totally lost. Ya, I know there are ways to manage your config for vi but it's not perfect. I find it's sort of like keyboard layouts like Dvorak. Sure it might be more efficient, which is debatable, but there is a huge value in being able to sit down at just about any keyboard and knowing the layout.
z3t4 5y ago
At one point it takes longer to implement a simple feature then it takes to rewrite the whole program, that's when you rewrite the whole program (using a sane amount of dependencies - as few as possible)
speed_spread 5y ago
I totally agree a specific IDE shouldn't be _required_ to operate the software platform. The IDE should ever remain a catalyst, accelerating a process that could be done by hand from the CLI whenever required. The good IDE should know about these different tools and present them in a a coherent manner. The I in IDE should mean more than integrating a compiler and debugger with a text editor. addendum: the "team rules" being kind of novel, these should be encoded in a human-readable file, actionable from the CLI as well as the IDE. I've been pondering for a while how such a workflow tool could be like.

maccard 5y ago

That's no different to requiring an arcane incantation of shell scripts that call maven, git, curl, docker, , etc. The advantage of having it built into IDEs or CI servers (and by built in I mean TeamCity/Jenkins providing it, not a self inflicted third party plugin) is that you can build around these steps. Imagine if all CI servers supported merge previews or mergebots - that workflow gets unlocked for everyone!

wing-_-nuts 5y ago
at least with the shell scripts I can quickly see what it does. I much prefer the unix philosophy of small bits of code that do one thing, and do it well. Such things can be combined to make bigger things. Want to make a plugin out of those individual scripts? Knock yourself out! Meanwhile, a decade from now, some engineer can actually reconstruct if needed. Much better than a 'binary blob' plugin that gets abandoned.

zcw100 5y ago

I used to do this, on and off, with vim. Hey customize this, and that, and add some special key bindings and plugins. Then you go to ssh somewhere and you're totally lost. Ya, I know there are ways to manage your config for vi but it's not perfect. I find it's sort of like keyboard layouts like Dvorak. Sure it might be more efficient, which is debatable, but there is a huge value in being able to sit down at just about any keyboard and knowing the layout.

z3t4 5y ago

At one point it takes longer to implement a simple feature then it takes to rewrite the whole program, that's when you rewrite the whole program (using a sane amount of dependencies - as few as possible)

speed_spread 5y ago

I totally agree a specific IDE shouldn't be _required_ to operate the software platform. The IDE should ever remain a catalyst, accelerating a process that could be done by hand from the CLI whenever required. The good IDE should know about these different tools and present them in a a coherent manner. The I in IDE should mean more than integrating a compiler and debugger with a text editor. addendum: the "team rules" being kind of novel, these should be encoded in a human-readable file, actionable from the CLI as well as the IDE. I've been pondering for a while how such a workflow tool could be like.