3 ms·
shouldn't everyone who touched code on a server have some basic tmux/vim config, at least vim? it's no rocket science and doesn't have to be perfect
by desmap 6y ago
shouldn't everyone who touched code on a server have some basic tmux/vim config, at least vim? it's no rocket science and doesn't have to be perfect
- onion2k 6y agoshouldn't everyone who touched code on a server have a basic tmux/vim config, at least vim? No. Obviously not. There are millions of developers who don't work that way.
- richbradshaw 6y agoI’ve been developing for a decade and have never used tmux and have use vim for probably ten hours.
- vidarh 6y agoThe specific tools are not really the point. The same applies whichever tools you need - sooner or later you'll need to cleanly set up a new machine, at which point committing your configs pays for itself.
- andybak 6y agoI can't think of anything that I need in a config that isn't a) a luxury or b) specific to my local machine. There's a few tweaks I miss when working in a remote shell but none are essential.
- vidarh 6y agoSo you can think of things that'd be useful, you just see it as a luxury. But the point is it's not a luxury once you commit the configs and setup scripts and turn it into a single command to deploy anywhere you want it. And what I found when I started doing that was that suddenly I was a lot less hesitant to let myself become dependent on time-saving tools because I knew they'd be available anywhere with ease. I can't imagine suffering through a default shell environment or a default editor config any more. But committing them is not just about remote machines, but about having a clean record of what is needed to set up any new machine I acquire as well.
- dividedbyzero 6y agoI've had to set up a new machine like, maybe four times in recent years I think. Except for one time (new employer) I just restored a new Macbook from a backup and was good to go. I don't edit code on servers unless in dire emergencies that are extremely rare (as they should), and nano will do fine for those. Everything is infrastructure-as-code and I like it that way. What work I do on remote hosts happens through e.g. JupyterLab.
- vidarh 6y agoI don't edit code on servers either, but I frequently need to debug systems, or do experiments or develop in containers set up for that purpose. As such it's not unusual for me to work with dozens of different environments in the course of even a week. It's not just about having my editor available, but being able to trivially easily pull in the basic tools to do what I want, and that is especially important during emergencies, but it's also about convenience in other situations. It sounds like you're lucky enough to deal with very simple environments. That's great. I'd still argue the cost in time of committing your config is so low that it'd be worth it. It takes pretty much one reinstall before it's paid for itself, or one instance of being somewhere without your usual environment. Or one instance of doing something silly to a config and forgetting what you changed. The nice thing about it is that it can start extremely light-weight - just literally a "git init" and .gitignore everything, and then gradually force add and commit.
- andybak 6y agoYeah. I still go with nano those rare times when I need to edit remotely. Vim just never seemed to fit my brain and I don't need to do this enough to make it work getting over the hump. The infamous "can't work out how to quit Vim" might have soured my initial experiences. That's pretty much all I remember from the first few dozen times I accidentally launched it because it was set as the default $EDITOR.