[therealmarv]

Well this is your use case. I use Linux every day but I never touch python code directly on remote systems (it's getting automatically or manually deployed). All my python code lives in virtualenv locally here. But I understand when people work for many projects they maybe want to encapsulate it more (vagrant etc.).

[annnnd]

Of course, use cases are different. In my case I usually deploy either automatically or manually, but in those rare cases when you can't replicate bug locally there is nothing better than vi. But of course, to each his own.

[rantanplan]

Debugging directly on the production system?

Yeah, nobody does that. Well, nobody who has any kind of serious operation going on.

If you can't replicate a bug outside a production environment you have a serious deficit in the devops department.

You should be able to stage a machine with a copy of the production DB/data and the same reproducible package(code) that currently runs on your production systems.

Everything else is just an accident waiting to happen.

[nameless912]

> Debugging directly on the production system? Yeah, nobody does that.

Uh, what bubble are you living in? Almost everyone does that to some extent. We can all pretend we're code ninjas with super clean deployment pipelines and strict policies, but all of us get lazy occasionally.

[thinkmassive]

Not to mention that, in any successful project, there are going to be systems that need to be looked at by someone else. It's great for the original developer(s) that they can use their IDE to access files directly in containers, but if I'm called to investigate a running system then I'm going to end up in a shell on those hosts.

The only place I can see this never happening is in large enterprises that have huge departments with slow enough turnover that "the accepted workflow" is easily passed on to new hires. Referring to everyone else as "mom & pop shops" makes it sound like the speaker is living in a Silicon Valley enterprise bubble.

I find it amusing to see that term used as an insult on a site largely populated by startups.

[rantanplan]

Sounds pretty self-serving to say that I "referred to everyone else", just because you want to justify sloppy processes. I only referred to those who do that, and I'm sorry if I'm bursting anyone's bubble here, but nope; not everyone does that!

Also a startup doesn't necessarily have requirements for serious ops, but it may, some day. Well if they want to be an enterprise at least. You do know what the goal of a startup is, don't you?

And btw, no I don't live or work for company in SV. Europe mostly, with a dash of Dallas, Texas in the mix.

In any case, I was hoping for engineering arguments, not personal attacks. :(

[fattymagoo]

dont no

[rantanplan]

"Almost everyone does that".

No they don't. I am not living in a bubble. You're describing a mom and pop shop.

And by the way you don't have to be a code ninja or have a super devops team for that.

You can have your code locally, point your DB config to a staging server with a copy(you do backups daily, don't you?) of production and boom!

Seriously now... elementary stuff. If you're still changing code directly on live systems you have a long way to go.

[nameless912]

And you're describing a pipe dream that doesn't happen in real engineering orgs. I think I can speak for most people here when I say that the best of DevOps intentions only last until your first fire. You can design for best practice, but odds are something will happen that requires you to jump onto a moving train and figure out what the hell is going on. That doesn't mean that DevOps is pointless, it just means that a dose of realism is required to understand how to do real engineering. Sometimes you just won't be able to do things the "right" way because you only have time to do them the "wrong" but still working way before your customer gets pissed. The real world has very different requirements than a management textbook.

[rantanplan]

Well I don't know what your friends, social or professional circle is, but it does happen.

What I describe is not out of a management textbook. This is really really elementary stuff if you want to sustain any serious operation.

Let me explain: so you're saying a customer is on fire. Let's say that a query generated by that customer for some reason it creates a spike in your DB. Let's say that it almost DOSes your system. You know it doesn't happen locally, with your dummy/fixture data and it doesn't happen with other users/customers. So some particular configuration of state(your DB) is creating this problem. What are you gonna do my friend? Retry the query on production while you have a debugger on the webapp process? Please... be serious.

Remember, it's only once you have to setup this kind of infrastructure(and you can scale it up or down depending on your resources). And then you can do business like a normal person. What you describe is like throwing my sanity out of the window every time there's a severe(or not) support issue ticket. It doesn't scale!

[WildUtah]

Our host, Paul Graham, talks about his first successful startup sometimes. It's ViaWeb, now Yahoo Stores, and it made him the rich investor he is today.

He edited the code live on the production server sometimes. And he did it in the repl, not by editing source files, so he didn't even have a record of what he changed that could go into version control.

When you're nimble and you need every advantage to compete, sometimes you have to be able to do things the hard way.

Not that I would recommend it; every ethical programmer in the galaxy has denounced the practice. And they have good reasons.

[thinkmassive]

>> in those rare cases when you can't replicate bug locally

> directly on the production system?

Why does 'non-local' have to equate to production? Are you able to use an IDE in your container/VM/cloud server?

[rantanplan]

Yes, PyCharm supports Vagrant, Docker etc.

My host system is Fedora but since our production code is deployed on Ubuntu, I have a Vagrant Ubuntu image. PyCharm reads the Vagrantfile and it has access to the virtualenv(python in our case) of the Vagrant's image.

UPDATE: I am not sure if that's what you were asking. Maybe this response(https://news.ycombinator.com/item?id=13543158) I gave is more relevant ?

[thinkmassive]

That VM/container is still essentially a remote system. Do you never ever log in to it? What types of instrumentation are you using to characterize the performance and operation of your app in the dev instance?

[rantanplan]

I can't characterize the performance of my app on a dev instance. I don't even think it's possible. You could characterize in the sense you do it for algorithms(with regards to time complexity).

But in general this is my(our) process.

- First I write the code.

- Then I test the code locally.

- Then I test the code on an instance with a copy of prod data. If I want to debug at this point, I run the web process locally while my DB configuration points at that specific server with the prod data.

- If it's code that spans across more than one subsystem(e.g. it also involves async celery task/queue servers) I test on a staging environment, that duplicates(as much as possible) the prod infrastructure.

- Then I deploy.

Obviously there are other various details, plus rollback plans in case something still goes wrong, but that's the gist of it.

[Daviey]

My developer machines I have a neovim setup with a bunch of extra config and plugins, but when doing remote work I often have to use vanilla vi or vim.. and I just put up with it.

If I need to do something significant, i'll scp the file around. I know vim can edit over ssh, but I honestly never do.

I've never tried vscode, but I am tempted to try the remote support: https://github.com/DonJayamanne/pythonVSCode/wiki/Debugging-...

[sametmax]

+1. I use VIM all the time on my remote servers, but never to dev.

[general_ai]

I prefer console in general, for everything. I've been doing this for 20+ years, and you can pry it from my cold, dead hands.

[dotancohen]

I've only been coding for 11 years professionally, but also as a hobby before that. Only in 2016 did I move most of my work out of VIM into an IDE: the Jetbrains family. That mostly started for better interactive debugging, but with IDEAVim handling 95% of my VIMisms I find that I'm simply coding in PyCharm and PhpStorm by default now.

The base editor is open source but you can get the full PyCharm for $99 per year. Worth every cent.

[Arizhel]

I've used PyCharm. The editing feature is beyond useless to me, because it does not have vim key bindings. How am I supposed to cut and paste code when commands like "y}" don't work? You actually expect me to use a mouse to select things or move the cursor? Ridiculous.

The only thing I've found PyCharm good for is doing other functions, like linting, not for the actual code editing. No IDE is any good for that. Luckily, PyCharm works just fine when the code it's working with changes on the filesystem below it because of the use of an external editor.

[xbrother]

There is VIM plug-in for Intellij family IDEs. It covers the great part of VIM functionality. It even supports some sort of VIM configs. "y}" works fine, as well as "yi{".

[therealmarv]

This sound you are trapped in vim keybindings. There is no need to use a mouse on "normal" editors.

[lenkite]

"y}" works with IdeaVIM. https://github.com/JetBrains/ideavim

[therealmarv]

Console for everything is the same like saying I never touch console, only GUI. There is a usecase for everything... I also want to see how you manage a bigger Java project from console with your 20+ years of expertise.

[xyzzy_plugh]

What about Java development necessitates a GUI?

I've never found I needed to use a GUI for developing software, outside of a browser.

[geoka9]

Working on a big legacy Java program spread over many dozens smallish files in deeply nested directory trees is very annoying without some IDE features (e.g. jump to definition). And I haven't seen a tool that can provide that kind of support for a classic text editor (Vim/Emacs). So you have to use an IDE (which necessitates a GUI).

To be fair, most other mainstream languages (except maybe Go) lack that kind of tooling too, but at least their cultures do not encourage liberal use of deeply nested directory trees and overengineered abstractions, the way Java does.

[xyzzy_plugh]

What? There are most certainly tools which provide jump-to-definition for vim/emacs.

With respect to vim, at the primitive end of the spectrum is ctags. At the opposite end there are things like the fabulous vim-go, which provides all the functionality that you'd expect in a traditional IDE. There are many similar plugins for other languages.

Regardless, I contest the idea that you have to use an IDE. I find traditional UNIX tools more than sufficient for programming in any language. I can find definitions with grep, use ctags and vim's chugger to manage definitions across many files in many directories. I'm also not limited to the scope of just one project. The tools I use and my expertise with them can then be applied to any language or problem. I use the same tools to write emails and commit messages.

Large legacy Java programs may be frustrating, but they're not all that bad, and certainly don't warrant requiring maintainers to learn and use an IDE.