• 92 Posts
  • 414 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

  • ono@lemmy.catoProgramming@programming.devSo You Think You Know Git? - FOSDEM 2024
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    9 months ago

    Mercurial has comparable features (though maybe not obvious to someone accustomed to git) without the usability problems that still plague git nearly two decades later. Hg’s interface was made with humans in mind. Git’s was made to cut you.

    (And it has cut so very many people that it’s consistently among the most popular topics in Q&A forums, and has even inspired comics.)

    Thankfully, git’s early cross-platform shortcomings were eventually fixed, so that’s at least some progress. I hope its UI and docs eventually get some love, too.




  • ono@lemmy.catoProgramming@programming.devCodeberg.org Opinions?
    link
    fedilink
    English
    arrow-up
    37
    ·
    edit-2
    9 months ago

    The interface is the best I know of, a lot like pre-Microsoft github. Especially important to me is that It doesn’t intercept my browser’s built-in shortcuts like github now does, or require javascript or bury things under submenus like gitlab does.

    The promise of federation is appealing, too.

    I plan to use it for new public projects, and might even move my old ones over.





  • ono@lemmy.catoProgrammer Humor@programming.devFLOSS communities right now
    link
    fedilink
    English
    arrow-up
    310
    arrow-down
    3
    ·
    edit-2
    9 months ago
    • Terrible format for archiving knowledge
    • Terrible tool for retrieving knowledge
    • Locks community access behind a corporate license agreement
    • Hands control of community-created content to a corporation
    • Prevents indexing by web search engines
    • Antithetical to interoperability
    • Privacy-hostile

    A web forum is far better in most cases. If you can’t manage to run your own, there are plenty of lemmy servers that will do it for you. Even an email list (with searchable archives) would be better than Discord.

    If you have collaborative documents that outgrow the forum format, use a wiki.

    If real-time chat is needed, irc or matrix.

    A project hosting its community on Discord is a project that won’t get my contributions.


  • ono@lemmy.catoProgramming@programming.devStrings do too many things
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    2
    ·
    edit-2
    9 months ago

    disallow list of known bad email providers.

    Imagine giving someone your phone number, and having them say you have to get a different one because they don’t like some of the digits in it.

    I have seen this nonsense more times than I care to remember. Please don’t build systems this way.

    If you’re trying to do bot detection or the like, use a different approach. Blacklisting email addresses based on domain or any other pattern does a poor job of it and creates an awful user experience.

    (And if it prevents people from using spam-fighting tools like forwarding services, then it’s directly user-hostile, and makes the world a worse place.)


  • ono@lemmy.catoProgramming@programming.devStrings do too many things
    link
    fedilink
    English
    arrow-up
    11
    ·
    edit-2
    9 months ago

    Checking MX in your application means you needlessly fail on transient outages, like when a DNS server is rebooting or a net link hiccups. When it happens, the error flag your app puts on the user’s email address is likely to confuse or frustrate them, will definitely waste their time, and may drive them away and/or generate support calls.

    Also, MX records are not required. Edit to clarify: So checking MX in your application means you fail 100% of the time on some perfectly valid email domains. Good luck to the users and support staff who have to troubleshoot that, because there’s nothing wrong with the email address or domain; the problem is your application doing something it should not.

    Better to just hand the verification message off to your mail server, which knows how to handle these things. You can flag the address if your outgoing mail server refuses to accept it.


  • ono@lemmy.catoProgramming@programming.devStrings do too many things
    link
    fedilink
    English
    arrow-up
    30
    arrow-down
    1
    ·
    edit-2
    9 months ago

    By the way, please don’t write regex to try to validate email addresses. Seriously.

    Amen.

    There are libraries for that; some of them are even good.

    Spoiler alert: Few of them are good, and those few are so simple that you might as well not use a library.

    The only way to correctly validate an email address is to send a message to it, and verify that it arrived.









  • ono@lemmy.catoPrivacy@lemmy.ml*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    10 months ago

    Whether to use encryption is a per-room setting, not per-server. It’s controlled by the person who creates the room, not the server admin. It’s on by default, and cannot be switched off later.

    Rooms can be created without it because that makes sense for large public rooms, like those migrating from IRC, where privacy would defeat the purpose.