Web Developer by day, and aspiring Swift developer at night.

  • 2 Posts
  • 153 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle





  • Because it’s not simply “distributing” the load; it’s actively hiding an instance as if it doesn’t exist. So what do they do when the next instance gets “too big” for their liking? Hide it, along side LW? And the next?

    Re-read my comment — specifically the second half where I offer a potential solution that would actually distribute the load more fairly without having to hide anything.


  • Honestly, it’s a short-sighted move made with hubris by the developer’s personal ideology. Both @nutomic@lemmy.ml and @dessalines@lemmy.ml admit in the PR that it’s not a good solution, but yet they continue any way — probably because it’s an easy “solution”, despite alienating 41% of their active user base.

    It’s a terrible trend in a lot of programming circles that programmers think because it is easy and it “works” (in that one circumstance) that it must be correct. This can be evidenced by browsing StackOverflow and reading the accepted answers for a lot of questions (SSL errors in software and disabling hostname verification or cert checks comes to mind).

    In my 18+ years of experience, if I find an “easy” solution to a complex problem, I keep looking for the correct solution. What is “easy” now will most likely lead to more complex problems down the line. And as they say, “if you can’t find the time to fix it right the first time, where are you going to find the time to fix it again?”

    Look, I get Lemmy is meant to be decentralized. Hiding away your biggest instance looks shady to outside users not in the know. The real solution is to “go door to door” to app makers and ask them to not default to any one instance of Lemmy (side note: randomizing a default server is not much better). If anything, add a link to join-lemmy where people can browse the list of ALL instances (yes, ALL of them) and let them make a genuinely-informed decision on their own. As a convenience, and API should be provided (assuming one does not already exist) so that apps can query a pageable/searchable list of existing/active instances (maybe also provide a link to their homepage too).

    Hell, if it makes everyone feel warm and fuzzy, the default sorting of returned values can be weighted by percentage of active users (i.e., higher percentages get lower weights to help promote smaller instances). This would help to round out the number of signups without excluding instances.

    But whatever developers do (not just Lemmy devs), do NOT overly dictate how people use your software “because I don’t like it”; lest you piss your user base off.

    /two-cents

    Edit: clarified a few points.










  • In my experience, this amount of conflicts typically occurs because 1) most people mass commit a bunch of (mostly unrelated) changes at once, which leads to 2) inexperienced/impatient devs to clobber incoming merge conflicts without doing proper merges (mostly because they can’t make heads or tails of the diffs).

    This is very easily mitigated if all developers would make small, related commits (with descriptive commit messages and not “committing changes”). This makes everybody’s life easier because 1) diffs are smaller and readable for conflicts, 2) the dev can see the progression of code through commit history, 3) broken code is more easily revertable (and traceable) if something goes wrong, and 4) it’s easier to cherry pick specific changes if the whole changes cannot be published all at once.

    Also, git pull --rebase is your friend and not scary at all. It applies all incoming changes first, then applies your new commits last. 9 out of 10 times it avoids conflicts.

    Lastly, use a GUI. There are plenty out there to suit your tastes, and I feel they are a safer and easier alternative than CLI. Some GUIs are very safe and even allow undo operations on most things.



  • Sometimes it takes a little unintentional embarrassment to drive a point home. It’ll make them think twice next time.

    What I mean by that is that as long as you’re not intentionally or maliciously trying to embarrass them, then you shouldn’t feel bad. You cannot always control how somebody receives information; nor should you. The best you can do is to be clear and polite in your communication. If someone’s feelings get hurt, that’s on them to reconcile, not you.

    This is genuinely like parenting a child: they need to develop their critical thinking skills, and to gain their own confidence. So they must be left to make their own mistakes to learn from. Your job is to give show them the tools to use, give advice when necessary, and be there to catch them when they fall; because they will fall.

    Doing this will help bolster their self-confidence and make them better mid-/senior-developers later in their career. Coddling them and constantly holding their hand will make them reliant on other people and prevent them from learning anything.

    Edit: also remember KISS. 😊



  • dohpaz42@lemmy.worldtoProgrammer Humor@lemmy.mlI may not be the brightest
    link
    fedilink
    English
    arrow-up
    20
    arrow-down
    2
    ·
    24 days ago
    sudo echo "# FYI quotes(") must be escaped with \ like \"
    

    👆 that is not a comment. That is a command that says to echo the text “# FYI quotes(” and then to do ) must be escaped like \ \" which is invalid syntax.

    I assume that startup script is reading the contents of the file and trying to echo them into another file? i.e., using the original file as a template, but is not escaping the input, hence the error — which you’re lucky that’s the problem you’re encountering and not something actually destructive like sudo echo "# foo" && rm -rf /*.