Just a basic programmer living in California

  • 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: February 23rd, 2024

help-circle

  • I’ve mainly worked as an employee so I don’t have as much experience with freelance gigs. But nearly every job I’ve had in 18 years has been through networking. Organizing and speaking at programming meetups opened a lot of doors for me. It gets a lot of attention on me while I get a chance to present myself as an expert.

    Eventually I’d worked with enough people that when I’ve been looking for work I find I know people who’ve moved to new companies that are hiring.


  • I’m gonna take a couple of stabs in the dark.

    According to this Stack Overflow answer using tee can prevent the prompt from drawing which makes it appear that a script has not terminated. The answerer’s workaround is to put a very short sleep command after the tee command.

    If this is what happened to you maybe the reason the script works in bash but not in zsh is because you have different prompts configured in those two shells.

    Another idea is to replace tee with sponge from moreutils. The difference is that sponge waits for the end of stdin before it starts writing which can avoid problems in some situations.


  • I’ve been using nushell as my shell for a long while. Completions are not as polished as zsh - both the published completions for each program, and the UX for accepting completions. But you get some nice things in exchange.

    I LOVE using nushell for scripting! CLI option parsing and autocompletions are nicely built into the function syntax. You don’t have to use the shell for this: you can write standalone scripts, and I do that sometimes. But if you don’t use it as your shell you don’t get the automatic completions.

    Circling back to my first point, writing your own completions is very easy if you don’t like the options that are out there. You write a function with the same name as the program you want completions for, use the built-in completions feature, and it’s done.


  • If the return type of a function is NonEmpty the value returned is guaranteed to be non-empty because it is not possible to construct an empty NonEmpty value. That’s the “make illegal states unrepresentable” mantra in action.

    At runtime you might get a list from an API response or something, and it might be empty. At that point you have a regular list. Following the advice from the article you want to parse that data to transform it into the types representing your legal states. So if the list is not supposed to be empty then somewhere you have a function that takes the possibly-empty list, and returns a value of type NonEmpty. But if the list actually is empty that function will fail so it has to be able to return or throw an error. The article uses the Maybe type for that which is one of the Haskell types for functions that can fail.

    Once you have parsed the input list, and successfully gotten a NonEmpty value the rest of your code can safely access the first element of the list because a value of that type is guaranteed to have at least one value.



  • Probably not very similar, but Git Butler is very interesting. It adds its own layer of management so that you can have multiple branches “applied” to your working tree simultaneously. It’s helpful when you have multiple changes that should go into different branches, and some that shouldn’t be committed - it has a system of lanes that help keep track of all that. Or you can test how changes from two branches interact.

    Last time I used it, maybe 6 months ago, it was rough around the edges so I didn’t stick with it. But they’ve done lots of work since then so I’m thinking of giving it another go. It is (last I checked) an all-in tool. When you’re using Butler on a project you probably won’t be able to use other git tools.


  • I think it depends. Lua is great for scripting - like when X happens do Y. I agree that makes sense for a case like Home Assistant. Sometimes you really want the result to be a data structure, not an interactive program, in which case I think more sophisticated configuration (as opposed to scripting) languages might be better.




  • hallettj@leminal.spacetoProgramming@programming.devWhy YAML sucks?
    link
    fedilink
    English
    arrow-up
    13
    ·
    edit-2
    6 months ago

    I agree - YAML is not suitable for complex cases that people use it in, like Terraform and Home Assistant. My pet peeve is a YAML config in a situation that really calls for more abstraction, like functions and variables. I’d like to see more use of the class of configuration languages that support that stuff, like Dhall, Cue, and Nickel.

    There is another gotcha which is that YAML has more room for ambiguity than, say, JSON. YAML has a lot of ways to say true and false, and it’s implicit quoting is a bit complex. So some values that you expect to be strings might be interpreted as something els.





  • A commit followed by a reset or commit --amend later is one more step than a worktree --add. Plus there have been lots of times when I’ve had some changes staged, and some unstaged debugging or experimental changes that I want to make sure not to commit, and thinking about how to pack all that away neatly so I could get back where I was seemed sufficiently obnoxious that I avoided doing whatever would have required a quick branch switch. Worktree would have let me pick up where I left off without having to think about it.




  • Yes, this is what I think of when I think of a “dead man’s switch”. It relates to the concept of a physical device that deactivates or activates if you let go of a switch, like a light saber for example.

    I think an interval of weeks would be more convenient than hours to avoid false positives. But I think Patrick Stewart’s character did daily check-ins in the movie Safe House. The dead man’s switch was actually the central plot point in that movie.