• 29 Posts
  • 927 Comments
Joined 6 years ago
cake
Cake day: May 31st, 2020

help-circle

  • Ephera@lemmy.mltoich_iel@feddit.orgich🟩iel
    link
    fedilink
    Deutsch
    arrow-up
    1
    ·
    1 day ago

    Ja, gut, ich sprach von dem fiktiven Szenario in dem wir Ranked Choice hätten. Also ja, auch da halte ich es für nicht so unwahrscheinlich, dass sie mit der CDU weiterregiert hätten. Aber theoretisch hätten sie ja vielleicht eine schwarz-grün-linke Regierung erwirken können, je nachdem wie die Sitzverteilung dann ist.


  • Ephera@lemmy.mltoich_iel@feddit.orgich🟩iel
    link
    fedilink
    Deutsch
    arrow-up
    5
    ·
    2 days ago

    Jo, hat im Konkreten betrachtet natürlich Vor- und Nachteile. Die Linke+Grüne wäre evtl. verhältnismäßig mit mehr Sitzen vertreten und hätte trotz offizieller Leitung durch die CDU evtl. eine stärkere Verhandlungsposition.

    Kann aber natürlich auch bedeuten, dass dann vielleicht die Grünen sich trotzdem zu einer schwarz-grünen Koalition hinreißen ließen, einfach weil Regierungsbeteiligung, und dann innerhalb der Koalition auch wieder Schwierigkeiten hat, weil die Linke ihre Kompromissvorschläge auch ablehnt.

    Also ja, ist kein Allheilmittel, das strategisches Wählen komplett abschafft, aber die Hoffnung ist eben trotzdem, dass es besser als die aktuelle Situation ist.


  • Ephera@lemmy.mltoich_iel@feddit.orgich🟩iel
    link
    fedilink
    Deutsch
    arrow-up
    15
    ·
    2 days ago

    Die Annahme ist, dass einige Wähler jetzt für Grün gestimmt haben, obwohl sie die Linke bevorzugen, weil es nicht klar war, ob die Linke über die 5% Hürde kommt, wodurch sie jetzt erst recht nicht über die 5% Hürde kamen. Mit unserem aktuellen System verpufft die Wählerstimme nämlich einfach, wenn man sie einer Partei unter der 5% Hürde gegeben hat.

    Bei Ranked Choice hätte man “1. Linke, 2. Grüne” wählen können und hätte in beiden Fällen dann der richtigen Partei die Stimme gegeben.










  • Ephera@lemmy.mltoich_iel@feddit.orgich🐢iel
    link
    fedilink
    Deutsch
    arrow-up
    10
    ·
    10 days ago

    Hab gestern prototypisch eine API hingezimmert, damit die Studentin das weitertreiben kann, wo mit dem aktuellen Stand quasi eine API-Anfrage reinkommt, dann wird eine Bibliothek aufgerufen, die erstmal selbst eine HTTP-Anfrage macht, um Quellcode herunterzuladen, diesen dann zu kompilieren, um dann aus dem Kompilat Meta-Information auszulesen.

    Achso, und natürlich macht die API das N mal, weil es N Elemente gibt, deren Meta-Informationen dabei aufgelistet werden sollen.

    Das hat sich auch richtig falsch angefühlt, weil man natürlich immer die Befürchtung hat, dass das auf ewig so bleibt, und dann sowas rauskommt, wie bei dir. 🥴


  • Ephera@lemmy.mltoProgrammer Humor@lemmy.mlTOML
    link
    fedilink
    English
    arrow-up
    2
    ·
    12 days ago

    I can understand the sentiment and would 100% agree for programming languages.
    But personally I actually like that it encourages a flat structure, because you do not want to be yakshaving the structure of your config file. Too much nesting means you will sooner or later run into configuration keys being nested under the wrong category, because your project context changed over time.

    And well, as I’ve argued in a few other comments already, I think non-techie users have a disproportionally simpler time when no nesting is used. They understand the concept of a heading and then just adding a line underneath the appropriate heading is really intuitive.
    You can just tell them to add the line certificate="/tmp/cert.crt" under [network.tls] and they will find a line in their config file which actually reads [network.tls] and they can just paste that line as-is.

    With nesting, they’d need to add it under here:

    network: {
        tls: {
            certificate: "/tmp/cert.crt"
        }
    }
    

    Which means:

    • You need some awkward explanation where they should nest it, or an explanation that e.g. “network.tls” translates to nesting.
    • They will ask whether they should indent the line you sent them.
    • Well, and it’s also surprisingly difficult to explain between which braces they should put the text, and that’s at the end of the braces, but not after the braces etc., if you’re talking to them on a call.

    It’s not even that I’m completely enamored with TOML, but this aspect is certainly growing on me…



  • Will mich da mal nochmal damit ausprobieren, weil ich mir erhoffe, dass es konfliktfreier über Systeme ge-synced werden kann, weil eben nicht mehr die gesamte Datenbank-Datei als geändert markiert wird, sobald man auch nur ein Passwort ändert.

    Aber ja, hatte das vor einer Weile schonmal probiert und war mir damals doch zu minimalistisch…




  • Ephera@lemmy.mltoProgrammer Humor@lemmy.mlTOML
    link
    fedilink
    English
    arrow-up
    2
    ·
    13 days ago

    VSCode is Electron, i.e. a webpage, so it’s not hugely surprising that they opted for the natively supported JavaScript Object Notation. And also shows that they don’t care for using the right tool for the job to begin with.

    Personally, I much prefer TOML over YAML, because it does not have significant whitespace, and because you can read the spec in a reasonable amount of time. It just has so much less complexity, while still covering the vast majority of use-cases perfectly well.


  • Ephera@lemmy.mltoProgrammer Humor@lemmy.mlTOML
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    14 days ago

    We just document that this is how you write the config file:

    [network]
    bind.host = "127.0.0.1"
    bind.port = 1234
    
    # etc.
    

    And that seems straightforward enough. Yeah, technically users can opt to use inline tables or raw strings or whatever, but they don’t have to.