Threads for karlinfox

  1. 6

    A bit surprised that neither this nor the other posts which mentions IDE talks about these features:

    • fuzzy search of all symbols in project. That’s the primary way to navigate across file — just type the name of the type you need.
    • fuzzy search of all symbols in the current file (ideally rendered like a tree widget, as in JB IDEs) — that’s the main thing to use when jumping within a file
    • extend region/expand selection/semantic selection (that is, selecting progressively bigger valid expressions) — that’s a universal editing tool which speeds up almost any rearrangement of code.
    1. 2

      They do mention it, near the bottom:

      I’ve gotten a lot of value from a few changes: Learning to use fuzzy-file-open, search, ripgrep, jump-to-definition, jump-to-uses, jump-to-errors etc to move around the codebase.

      1. 3

        Yeah, this is what I mean: this list dodges the three things I find most valuable.

    1. 2

      Why would one run Firecracker instead of Raspian? Honest question.

      1. 15

        Firecracker is a fast, lightweight virtualization tool. It was open sourced by Amazon and is part of the stack that lets AWS Lambda run tons of tiny “functions” in isolation from each other on a single server.

        You still need an OS underneath, since the virtual machine needs a host to provide storage, networking, etc. (Not to mention the filesystem images normally used under Firecracker are very minimal, so you can’t really develop or debug in that environment.)

        The more reasonable question is probably, “why use Firecracker instead of Docker?” In that case: Firecracker gives you much stronger security boundaries between “micro VMs” than Docker does between containers. If you don’t need that (i.e., all your containers are running code you trust) then it almost certainly isn’t worth the learning curve to go with Firecracker.

        1. 2

          Thanks - that’s helpful. In that case, it sounds more of a gVisor than a Docker to me.

          1. 4

            What’s the overhead difference between the two?

            1. 4

              Both gVisor and firecracker are “slow” but useable and in this case, being a raspberry pi I’m going to guess that performance is not a huge limiting factor. gVisor can be ridiculously slow in many cases - they used to talk about performance penalties for “syscall heavy applications”, which is just a ridiculous statement to make. (Looks as if they’ve updated their perf docs recently: ) . Firecracker even though billed as ‘fast’ trades a slower run-time for a faster boot time although it appears there are plans to fix that.

              Having said that docker is unsafe at any speed. The claims of isolation in that ecosystem are kinda like the marketing claims from database companies that write to /dev/null.

        2. 1

          When you primarily intend to run containers on it, I suppose.

        1. 1

          I’ve solved my need for fast navigation with my own tool named “wd” (on github).

          If your brain works better with numbers than with “human-readable” mnemonics then give it a try. For example, wds2 will save the current directory into $WD2, and you can jump back to it with wd2. Slot zero is even shorter with just wd.

          It supports named schemes with autocompletion, so you can make one for each “project” context.

          1. 1

            “one person in a pair can hold the context while the other person in the pair gets interrupted. We could get back to work in seconds.”

            (Comment by James Grenning)

            I totally agree with this.

            1. 3

              I have to disagree, strongly. Pair programming as an 8-hour-per-day pattern is a terrible idea. It’s good to pair occasionally when it’s useful, but it shouldn’t be the default. After about 2 hours, it starts to burn people out and, as they tire, the “passenger” turns into a nonparticipant anyway. As a constant arrangement, it’s just another way for MBA-culture colonizers to shove mandatory extroversion (open-plan offices!) down programmers' throats.

              Also, environments that expect programmers to be constantly available are inherently broken and founded on culturally harmful assumptions (that programmers are low-status peons who can be expected to be available, and evaluated on their pliability, because they aren’t doing anything important). I might be completely wrong here, but it sounds like you’re trying to save “Agile”/open-plan culture and it isn’t worth saving. I don’t want to “get back to work in seconds” when pinged for an impromptu status update or context switch; I want a level of respect that makes them not happen (except in emergencies, of course).

              1. 2

                I’m pretty enthusiastic about pair programming, but I don’t think you can do it more than about 5 hours per day, and reaching that level requires constant attention to fatigue, hunger, and your partner’s feelings; and it also almost certainly requires switching pairs at least once a day.

                1. 1

                  Fair enough. To make it clear, I think that pairing to solve a specific objective is a good thing. Making software environments more collaborative in general is also good. When two or more programmers realize that the most efficient way to achieve a specific task is to set aside time and pair, that’s exactly what they should do.

                  I don’t like mandatory or permanent pair programming, because people often get their best work done alone, and I especially don’t like the idea that pair programming should be used as a patch to allow business people to treat us badly because one person can take the silly interrupt and the other, supposedly, can hold the context. That’s an unrealistic expectation, first of all, because the other person’s going to want to know about the Political Event That Just Happened; secondly, we should really be focused on getting our status to a point where we’re not interrupted over executive nice-to-haves, but only when the business situation absolutely requires it and we can “save the day”. One hopes, of course, that the number of days that need saving is small.

                  1. 1

                    I think there are some kinds of work that are best done alone, and other kinds that are best done in pairs.

                    I’m glad I’ve never worked in the kind of workplace you’re talking about.

              2. 1

                It would be great to see that studied like the other topics in the article. I’ve only liked pair programming for knowledge transfer, but if reducing interruption cost is a replicable effect of pairing that’d be great evidence for its value. Fingers crossed some researcher takes it up. :)

                1. 1

                  Subjectively, I think pairing does reduce my distractibility a lot. Like, my focus with pairing and my focus without pairing are not even in the same ballpark. It’s not because one member of the pair takes the distraction while the other sits there meditating, though. It’s because I don’t read Lobsters or listen to the conversation in the other room when I’m working to communicate with my pair; it might also be because third parties are more reluctant to interrupt our conversation than they would be to talk to one of us alone.

                  For many people, the biggest benefit of pairing may be knowledge transfer, instant code review, uniform coding standards, or bringing to bear a greater diversity of experience on the problem at hand. For me, it’s focus, by a mile.