Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)NH
nickwitha_k (he/him) @ nickwitha_k @lemmy.sdf.org
Posts
9
Comments
2,235
Joined
2 yr. ago

  • In that case, my suggestion would be to target implementing a REST API with OpenAPI (formerly Swagger). There are server code generators for both Rust and JS (multiple flavors, I think).

    Basically, the workflow is something like this:

    1. Create your API spec skeleton (YAML or JSON, pick your poison). This will have all of the required sections like info
    2. Pick your first endpoint and define it in the paths section. Probably start with during simple like a GET. This will mean that you mainly have to worry about defining your responses (at minimum HTTP2XX and HTTP4XX, preferably with a catchall error response for HTTP5XX responses) and their schemas.
    3. Run the code generator. This should generate files with stubbed-out definitions for interfaces (or the equivalent for your language of choice) for your response methods. Generally, you do NOT want to add any code to these files as they will be overwritten anytime you update your API spec.
    4. Implement the methods to handle the stubbed out interfaces. Ex. A hello-world interface would likely need to be implemented with a method or function that returns the string "hello world".

    The reason that I recommend OpenAPI in writing REST APIs is that it helps to layout the API contracts before you even start coding. This helps with keeping typing consistent, give you a clear milestone for implement, and makes creating clients really easy.

    Extra benefit is that OpenAPI is (mostly) language agnostic, so, as long as you have a codegen or some good boilerplate, you can use it for any language, which can give you a safe place to start when learning a new language.

  • Hard no. The reaction is absolutely warranted. The same sorts of people who push anti-electoralism/accelerationism are happily asking the sick people, who they helped prevent from getting treatment by installing craven right-wingers, to die for them. That is beyond fucked and should never be met with anything but scorn and derision.

    It's the same fucking story again and again. The cowards want to force things towards violence and not be at risk themselves. Asking sick people to do it for them? No. The only ethical response to someone suggesting that is "go fuck yourself".

  • The FCC, which licenses radio spectrum and makes the rules for device certification is part of the Executive branch. So are the CFPB and the SEC, or what's left of them. He's literally, corruptly leveraging his office to benefit his cons and preventing regulations from applying to himself and his cronies.

  • I recommend Kinoite, if you're doing anything graphical. Gnome support for DRM leases hasn't been great. Saying that really does pain me as I still think that Gnome 2.x is my favorite DE that I've used.

  • In a world not dominated by unfettered capitalism, sure. That's not the one that we live in however and this tool has both been built on stolen and unlicensed intellectual property as well as being used explicitly to harm people's livelihoods while replacing their work with objectively inferior plagiaristic amalgams.

    AI companies also refuse to obey the rules of the Internet and continually DDOS sites that request crawlers and scrapers not do so, necessitating creation of whole new types of software to defend against their malicious behavior.

    And on top of all that, they have substantially increased greenhouse gas emissions and are actively consuming potable water in a manner that makes Nestlé execs hard. Putting the planet's biosphere at greater risk and unnecessarily increasing water scarcity.

    Nah. Simping for AI companies is the irrational take. The value that they provide to humanity is, outside of some niche use cases, marginal at best and will likely never come close to making up for the harms that they are causing to humanity for a quick buck and to increase worker oppression.

  • Oh, absolutely. The thing that is weird is being non-x86 hardware and explicitly implementing the translation layer in hardware that has minimal field configurability (they did have the capability of loading something similar to microcode). It makes sense in some ways (performance being a big one) but, seems like it would be vulnerable to potential changes in the external ISA.