1. 2

    I don’t get this sort of thing at all. For me, j and k motions are used constantly, and I don’t know of any other commands that substitute well. I even set up J and K to be 10j and 10k, respectively, because I often find { and } not that useful. I don’t want a plugin to turn them off, because I’m not sure what they plan to replace them with.

    Meanwhile, I very rarely use h and l. I find them super-tedious to move more than a few chars at a time. I don’t see why anyone would use them over w and b. I don’t need a plugin to convince me not to use them - I’m already convinced.

    1. 1

      Meanwhile, I very rarely use h and l. I find them super-tedious to move more than a few chars at a time.

      What do you do if you want to change something like FooBarFoo to FooFooFoo or similar middle-of-the-identifier edits where w/e don’t consider the terms distinct? I seen people recommend f<letter>c<motion> but I’ve always thought counting letters to use with the f motion takes more time than leaning on h/l. Similar story for forward/backward search when your target is on the same line.

      1. 1

        ;' repeats the last f/F/t/T motion, and,’ does the same in the opposite direction. If I’m in a situation where counting would be necessary, it’s sometimes faster to spam ;' a few times, and if I accidentally pass it, use,’.

        It’s not elegant, but it works well for those situations where you expect `fB’ to match but it doesn’t.

        e.g. to s/FooBarFoo/FooBarQuux/, `fF;cwQuux’.

        Usually there’s other motions that’ll work in context too, depending on what text surrounds it.

        1. 1

          I would do fBctF for that. I find it easy because I’m already thinking about “I want to change Bar to Foo right up to the next Foo”, so the letters to to f and t to come to mind easily. If I’m h/ling, then I have to either try to count letters, which is distracting, or hold one down, probably overshoot and need to go back, which is also distracting. The whole thing I like about Vim is how, once you commit certain things to instinctive memory, you spend very few mental cycles thinking about how to make an edit you want to make or waiting to switch between mouse and keyboard.

          It’s also cool that Vim is almost a completely different program for everyone who uses it and can fit many different mental models about how to edit text.

          1. 1

            It depends how many characters you want to change. When it is just “Bar”, I’d probably use 3s.

      1. 2

        It’s a subtle way of requesting human machines.

        Maybe for many companies it is, but that’s an unfair generalization.

        (First, to be clear: side projects are far from a make-or-break when I look at candidates. It provides additional information that contributes to the overall picture of the programmer—qualities that might be demonstrated elsewhere.)

        When I look for a passionate programmer, I want someone who is going to contribute that passion to the team. If by “machine” the author means someone who’s going to sit down and mechanically pump out code, then this is the antithesis of the team that I want to be a part of. I want organic candidates that contribute not only code but to the processes, knowledge, and culture of the team. I want someone who will work well with others, but isn’t afraid to speak their mind.

        Don’t be turned off by all requests for side projects or code samples. My advice would be: be yourself. It is painfully obvious when someone forces “side projects”, or simply commits coursework. That is mechanical. If you do not express passion or interest for your career in that way, then demonstrate it in another, even if it’s in writing. Make me interested enough to interview you so that you can really speak to your interests.

        But don’t try to state what isn’t there. I’m often let down when someone states skills on their resume or elsewhere that they don’t actually possess and then can’t answer the most elementary interview questions about them. I’m disappointed when someone provides code samples or “side projects” that look interesting, but turn out to be code copied or slightly modified from elsewhere (someone else’s project, coursework, training sites, etc).

        1. 33

          On HN, Twitter, reddit, and Medium I am told to have side projects to be employable. My thoughts:

          a) I have side projects to learn and have fun, not to impress an interviewer. My side projects are for fun, exploration, experimenting, etc. They may not be finished or polished (or they may be!). The idea that I should give my leisure time outside of work to build stuff for the sake of finding better work is ridiculous to me. Granted, sometimes you can do both at the same time.

          b) In the handful of startups and big companies I’ve been associated with, I’ve been the only person in the team that has an active GitHub profile or other open source contributions. Most of my coworkers don’t code outside of work and are doing just fine; some having worked at “prestigious” companies. People need to understand that this isn’t actually the “norm” in the real world.

          1. 20

            Another ugly detail that’s often glossed over is that most of the people with substantial open source contributions (meaning that they led projects that are now used all over the world and can make money consulting) had the opportunity to work on open-source software on paid time.

            In a typical closed-allocation/authoritarian company, these aren’t the best hires, because they often expect to be able to work on open-source software (it’s how they got where they are) and it can inspire resentment. I’ve seen top-notch people actually get let go because middle managers got sick of explaining to the plebs why they couldn’t work on externally visible projects while someone else could.

            The more progressive companies have recognized that high-IQ people need something more like a research environment and encourage them to speak at conferences and contribute to open source projects and publish papers. However, getting into these companies is very difficult and they’re inaccessible to garden-variety software engineers.

            1. 4

              FWIW, I have recommended this, but mainly for people who don’t have much formal experience or education to get their first junior position. I think it’s a little crazy to require experienced professionals to also have open source side projects to be employable.

              1. 2

                I have side projects to learn and have fun, not to impress an interviewer. My side projects are for fun, exploration, experimenting, etc. They may not be finished or polished (or they may be!). The idea that I should give my leisure time outside of work to build stuff for the sake of finding better work is ridiculous to me. Granted, sometimes you can do both at the same time.

                That’s exactly what I want to see in a candidate!

                Not having side projects is far from a deal-breaker, but it is additional information useful in evaluating the candidate. The projects you describe are precisely what I want to see—not something that feels forced or is clearly put together to demonstrate certain concepts. Or coursework. Show me something derived from passion and/or playful exploration.

              1. 1

                I’d like to elaborate with my perspective:

                I pair program with others at work. I’m the only one out of the team that lives on the command line, and have been using Vim for well over a decade (and now also use Emacs with Evil); the other programmers (sans one, who also uses Vim) use whatever editor the others seem to recommend. Most recently, that editor was PHPStorm.

                I immediately reject PHPStorm because it is non-free/libre. But watching them use it is interesting. In particular, there is one programmer that really understands its features and refactoring tools—he doesn’t often use them, but when he does, I’m quite impressed. There are some features that I found would be convenient (and there are some that I did adopt in Vim/Emacs where packages were available).

                When we were researching this programmer before his interview a couple years back, we say a post on one of his social media accounts that expressed very strong distaste for Vim and Emacs users, and said that he likes editors that can “write the code for him”. And there, I think, is where people miss the point.

                Yes, these features are very convenient—when they can be used; they are rigid, and usually (as @steveshogren stated) cannot be part of a large composition. They also often require a clumsy GUI interface, which isn’t very (or at all) scriptable. So your editor might be able to write code for you—a small percentage of that time. When you get to use those features, it feels pretty good; but most of the time, you’re typing. Maybe using some auto-completion or auto-formatting.

                From the reverse perspective, the others are impressed by the efficiency with which I edit any text—it might be code, it might not. It’s easy to write macros around Vim commands, and trivial to do so: I’ve taken over the keyboard a few times just to open the file in vim and largely automate a task. But perhaps one of the most notable things I’ve seen was that, when editing files that aren’t part of a project that’s registered with their IDE, or non-source files, they often use other programs. And even if they did use PHPStorm, it doesn’t recognize the file format, so many of their benefits disappear.

                But Vim and Emacs aren’t the only useful tools—I also make aggressive use of standard GNU tools like grep, awk, sed, cut, sort, uniq, shell one-liners and scripts, etc; those are written to be components in a pipeline, and are fundamentally composable; they work on any file, source or not. This allows for far more than text edition: you can do data processing/analysis, reporting, scripting, etc. Between the command line and my editors, I don’t need any other programs to accomplish most sophisticated tasks that others would need wholly separate programs to do. And between editor macros/scripts, piping to external programs, and shell scripts / pipelines, I can reproduce the important part of those refactoring tools to the extend that I need.

                tl;dr: This falls under the same philosophy as that of Unix: small programs (or Vim commands ;)) that do one thing and do it well, use the universal interface (text), and that work as part of a pipeline. Editors that try to think for you lose out when they haven’t thought of what it is you’re trying to do—and that’s constraining, and a hacker’s antithesis.

                1. 3

                  I’m using something similar and for me it’s quite convinient; I’ve set up a container-based encryption on an OpenBSD virtual machine on a remote server (based on softraid0). The passwords are stored there in plain text files and I use a script to mount the container and unmount it.

                  When I need a password, I’m ssh'ing to the server (public key authentication, so I type the password only once for some time), I mount the container (so I type the password for the container here), and I grep for the proper file, copy/paste the password and unmount the crypto container, all by using simple bash 1-letter aliased commands.

                  I’ve also set up an automatic backup script working once a week that additionally encrypts the whole container file with a generated password based on current date (the algorithm is in the backup script and in my head) and I’ve set up multiple scripts on some of my computers (laptop, desktop) to pull those backups, and push them to some other remote servers like google drive, so I know I won’t lose any password even if this remote server from some reason will go down, or my Internet access will be limited.

                  1. 2

                    copy/paste the password and unmount the crypto container

                    There are other benefits to certain password managers, such as ones that fill in fields directly in your browser (e.g. the built-in FF password storage): it protects against clipboard / X selection monitoring and against certain side-channel attacks like Van Eck phreaking.

                    The latter is a problem because, in order for you to copy the password to your clipboard, it is displayed on your screen. Then, in copying it, you expose your password in plaintext to a system that doesn’t benefit from the same security considerations as the system storing your password. A less sophisticated form of screen capture is also possible: malicious software simply capturing an image of the passwords you have on your screen.

                    I store my passwords in one of two places (but not both): for general accounts, I store the password using FF’s (GNU IceCat, in my case) password manager with a strong master password. It uses 3DES for encryption (which is fine), but there’s reason for strong caution: FF is a large program with a huge attack surface; an encrypted file on disk using simple, standard, specialized tools is likely a better idea. The especially sensitive ones I store encrypted on disk. To mitigate the problems I mentioned, I copy the password to the clipboard by piping it to xclip as such:

                    $ your-pw-cmd | xclip -i -l 1 -selection clipboard -quiet

                    (You’ll need to use X11 forwarding over SSH.)

                    -l 1 (“loop” 1) tells xclip to satisfy only one selection request before quitting, meaning that you can only paste the password once. So if an attacker queries the clipboard, xclip will exit, you won’t be able to paste your password, and you’ll know that your system was possibly compromised (at the very least, that you should change your password). -quiet causes xclip to run in the foreground so that you can see when (and that) it exits.

                    When generating a new password, I pipe it directly to the file or, if using FF’s password manager, to the clipboard:

                    # -l 2 so that I can paste it in the verification field as well
                    pwgen -sy 64 | xclip -i -l 2 -selection clipboard -quiet

                    This way, you avoid both selection monitoring and displaying the password on the screen, thereby avoiding screen capture (Van Eck or otherwise).

                    If anyone has other suggestions for avoiding these attacks using standard tools, I’d love to hear your thoughts.

                  1. [Comment removed by author]

                    1. 9

                      You are the next pdf.js vuln away from regretting that decision. :)

                      1. 1

                        Or the next time someone borrows their machine.

                      2. 7

                        It depends on the adversary.

                        If you’re carrying around your laptop that you shut down frequently, and want to prevent someone from grabbing it and reading your disk, then an encrypted disk is helpful toward protecting your passwords.

                        But often times your disk is already decrypted. If you suspend your laptop rather than shutting it down, for example, someone could potentially access your disk with a suitable exploit or by knowing your account password. A cold boot attack could be used if cracking is too difficult.

                        But they might not need physical access: any software running on your system (given the appropriate permissions), if exploited, would be able to read your password file. It’s not a matter of trusting your software; I use a fully free GNU/Linux operating system and do generally trust the software I’m running and the communities behind them. But bugs exist, and it only takes one of them to potentially compromise data. If the box storing your passwords on executes any random program you download, that’s an even greater risk.

                        If that box also runs your web browser, then you’re stepping into a minefield—it automatically downloads and executes arbitrary, untrusted programs (most often JavaScript) on your computer. If you take care to disable JavaScript and use other tools, great, but there could also be exploits elsewhere, like the image processor, or font renderer. It’s one thing to have software that has an unpatched CVE but is segregated from everything but the user; it’s another to have an unpatched browser (or a 0-day) that can be immediately exploited at any moment.

                        If you don’t want to maintain another password, a simple GPG-encrypted file works well, since it’s a password you already know and use frequently (unless you don’t use GPG at all). If you use an editor like Emacs that transparently supports GPG-encrypted files, then it makes it all the easier. You then have a much smaller attack surface to worry about: an attacker would have to be able to access the data in memory as it’s being used, hope that it was swapped to disk (which some programs will prevent), trigger a coredump, etc.