• 0 Posts
  • 20 Comments
Joined 3 years ago
cake
Cake day: August 2nd, 2023

help-circle
  • I completely agree with the general assessment, but then there are always pesky exceptions. In this case the list entered a JavaScript frontend from the yaml header of machine generated content pages for the website framework Hugo. And, of course, after finding the bug, it is clear that things could have been done differently and the issue easily avoided, but I also don’t think this was a completely unreasonable design. Since Hugo actually supports JSON headers (not just via the yaml parser, but thanks for that tip!), that was a quick fix. But I’m also somewhat amazed that it was possible for the strung-together fairly standard set of Python libraries (primarily pyyaml) to not get the strings properly quoted.


  • backgroundcow@lemmy.worldtoProgrammer Humor@programming.devTOML
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    4 months ago

    Just the other day I had a list show up as [“a”, “b”, “c”, “d”, “e”, false, “g”, “h”, “i”].

    The issue was that, without me being overly aware of it, the data was going through a data -> yaml -> data step.

    Yes, the data -> yaml filter was broken for not putting general strings in quotes. But IMO the yaml design invites these odd “rare” bugs.

    I used to like yaml, but was happy to see Toml taking the niche of human-readable-JSON, but felt the format for nested key-value was a weird choice. However, I’ve always felt we could just have extended JSON a bit (allow line breaks, comments, if the outermost data type is an object, the curly brackets may be omitted).


  • Even knowing the “correct answer” to this riddle for as along as I remember, I don’t think it is right. For someone looking for how to handle this in an interview, I’d go with this:

    I will fetch a friend or colleague to look at the bulb as I test the switches because:

    • It is by far the most obvious solution that literally everyone faced with this problem actually would use. It is easy to understand and will be easy to explain to others (if you, e.g. need to present or document what you did).

    • It is also a better solution: it is by far more robust against a large number of failure modes: e.g., if it turns out you are testing the wrong switch, the bulb is broken, more than one switch turn on the light, etc.

    • It scales better: the same solution trivially extends to N number of lightbulbs controlled by M number of switches; and at large N it will save time not having to reach each bulb.

    • It gives the opportunity to interact positively with a friend/coworker. Helping each other out with small necessary tasks builds team cohesion and work environment, and thus lowers the barrier for further collaboration, making us a more effective team in the longer run.


  • What kind of nerds do you claim to be in this thread?! Despite being late, I see no mention of the xkcd color survey: https://blog.xkcd.com/2010/05/03/color-survey-results/

    As far as I can read just by eye, its “mustard” or “olive”, but funnily it also seem close to the one someone annotated: “really? this color again? i have nothing against colors personally, but this one just stands out from the rest as unusually unattractive. i almost feel sad for it, but it made the decision to be that color so it has to find a way to deal with it.”

    But, someone, feel free to dig into the hex codes to give a more definite answer.




  • MasterCard’s and Valve’s statements seems to point at Stripe and PayPal as the ones who folded to the pressure. These payment processors then cited MasterCard’s rules to back up their change in policy.

    MasterCard now clarifying that the payment processors are over-interpreting the rules and anything legal is ok seems a very good thing here. Valve should be able to go back to Stripe and PayPal with this and say: “Hey, you’ve misunderstood the rules you are quoting; MasterCard themselves say anything legal is ok, and that is the exact policy we’ve been using!”



  • These two are not interchangeable or really even comparable though?

    For GNU Make, yes they are. These are fully comparable tools for writing sophisticated dynamic build systems. “Plain make”, not so much.

    [cmake] makes your build system much, much more robust, far easier to maintain, much more likely to work on other systems than your own, and far easier to integrate with other dependent projects.

    This is absolutely incorrect. I assume (although I have never witnessed it) that a true master of cmake could use it to create a robust, maintainable, transferable build system. Very much like there are people who are able to make delicate ice sculptures using a chainsaw. But in no way does these properties follow from the choice of cmake as a build system (as insinuated in your post), rather, the word we are looking for here is: despite using cmake.

    I apologize for my inflammatory language. I may just have a bit of PTSD from having to build a lot of other people’s software through multiple layers of meta build systems. And cmake comes back, time and time again, as introducing loads of obstacles.







  • … weighs one gram … An amount of hydrogen weighing the same amount has exactly one mole of atoms in it.

    Not only was this never true - the sentence would have to have say “An amount of carbon-12 atoms weighing 12 times this amount has exactly 1 mole atoms in it” (far less elegant) – but not even this is true any longer after the fuckup in redefining the mole in 2019, after which all these relations between amount of substance and mass are only approximate.