No relation to the sports channel.

  • 3 Posts
  • 452 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle








  • Rust does memory-safety in the most manual way possible, by requiring the programmer prove to the compiler that the code is memory-safe. This allows memory-safety with no runtime overhead, but makes the language comparatively difficult to learn and use.

    Garbage-collected compiled languages — including Java, Go, Kotlin, Haskell, or Common Lisp — can provide memory-safety while putting the extra work on the runtime rather than on the programmer. This can impose a small performance penalty but typically makes for a language that’s much easier on the programmer.

    And, of course, in many cases the raw performance of a native-code compiled language is not necessary, and a bytecode interpreter like Python is just fine.



  • fubo@lemmy.worldtoProgramming@programming.devHow to be a -10x Engineer
    link
    fedilink
    arrow-up
    63
    arrow-down
    1
    ·
    edit-2
    9 months ago

    Some other ways:

    Cultivate bitterness.

    Find the pessimists in your organization, and disappoint them.

    Make mean cynicism a part of your workplace culture. Do this by example: Promote mean cynics and put them in charge of things. But do it also by conversion: Behave in a way that makes mean cynics’ view of the world correct.

    Reward bad personal habits to create internal conflicts between work and health.

    If someone skips sleep to finish a project, give them a bonus. This gives them an internal conflict between approval and health, and teaches them that they can sacrifice their health to receive a reward.

    Encourage a hard-drinking culture in teams that have stressful roles that demand team cohesion, like SRE or Ops teams with on-call requirements. This gives them an internal conflict between their support network and health.

    If someone is sick, injured, bereaved, or otherwise suffering: Make it clear how much their condition is inconvenient to their coworkers, and how much their projects are impacted by their absence. Assure them that all will be well once they can conclude their personal problems and commit to the team. Do not, however, offer them any specific help; if they express specific needs for accommodation, disregard them as idle and unrealistic wishes.



  • If DNS is transiently down, the most common mail domains are still in local resolver cache. And if you’re parsing live user requests, that means the IP network itself is not in transient failure at the moment. So it takes a pretty narrow kind of failure to trigger a problem… And the outcome is the app tells the user to recheck their email address, they do, and they retry and it works.

    If DNS is having a worse problem, it’s probably down for your mail server too, which means an email would at least sit in the outbound mail spool for a bit until DNS comes back. Meanwhile the user is wondering where their confirmation email is, because people expect email delivery in seconds these days.

    So yeah … yay, tradeoffs!

    (Confirmation emails are still important for closed-loop opt-in, to make sure the user isn’t signing someone else up for your marketing department’s spam, though.)


  • fubo@lemmy.worldtoProgramming@programming.devStrings do too many things
    link
    fedilink
    arrow-up
    10
    arrow-down
    2
    ·
    edit-2
    9 months ago

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

    If you’re accepting email addresses as user input (e.g. from a web form), it might be nice to check that what’s to the right of the rightmost @ sign is a domain name with an MX or A record. That way, if a user enters a typo’d address, you have some chance of telling them that instead of handing an email to user#example.net or user@gmailc.om to your MTA.

    But the validity of the local-part (left of the rightmost @) is up to the receiving server.


  • fubo@lemmy.worldtoProgramming@programming.devStrings do too many things
    link
    fedilink
    arrow-up
    68
    arrow-down
    1
    ·
    edit-2
    9 months ago

    Any time you’re turning a string of input into something else, what you are doing is parsing.

    Even if the word “parser” never appears in your code, the act of interpreting a string as structured data is parsing, and the code that does parsing is a parser.

    Programmers write parsers quite a lot, and many of the parsers they write are ad-hoc, ill-specified, bug-ridden, and can’t tell you why your input didn’t parse right.

    Writing a parser without realizing you’re writing a parser, usually leads to writing a bad parser. Bad parsers do things like accepting malformed input that causes security holes. When bad parsers do reject malformed input, they rarely emit useful error messages about why it’s malformed. Bad parsers are often written using regex and duct tape.

    Try not to write bad parsers. If you need to parse something, consider writing a grammar and using a parser library. (If you’re very ambitious, try a parser combinator library.) But at least try to recall something about parsers you learned once way back in a CS class, before throwing regex at the problem and calling it a day.

    (And now the word “parser” no longer makes sense, because of semantic satiation.)

    By the way, please don’t write regex to try to validate email addresses. Seriously. There are libraries for that; some of them are even good. When people write their own regex to match email addresses, they do things like forget that the hyphen is a valid character in domain names.