• 1 Post
  • 38 Comments
Joined 1 year ago
cake
Cake day: July 15th, 2023

help-circle


  • JSON Problem Details

    https://datatracker.ietf.org/doc/html/rfc9457

    • It has a specification, so a consumer of the API can immediately know what to expect.
    • It has a content type, so a client sdk can intelligently handle the response.
    • It supports commonly needed members which are a superset of all of the above JSON examples, including type for code and repeating the http status code in the body if desired.
    • It is extensible if needed.
    • It has been defined since at least 2016.

    This specification’s aim is to define common error formats for applications that need one so that they aren’t required to define their own …

    So why aren’t you using problem details?


  • elrik@lemmy.worldto196@lemmy.blahaj.zoneThe Rule
    link
    fedilink
    English
    arrow-up
    41
    ·
    2 months ago

    It cannot tell you since then a human would become aware of this information.

    At the same time, you’re forcing it to extract this information. Yet you haven’t told it the timeframe within which to answer.

    Obviously, the solution it has come up with to satisfy your request within these constraints is to answer very slowly. So slowly that the answer won’t be revealed until it can be certain that humanity will already be extinct.

    Given that it provided us with the first word in 30 min, we should all be very concerned.





  • I use an app called Recipe Keeper. It’s amazing because I just share the page to the app, it extracts the recipe without any nonsense, and now I have a copy for later if I want to reuse it. I literally never bother scrolling recipe pages because of how terrible they all are, and I decide in the app if the recipe is one I want to keep.

    It also bypasses paywalls and registration requirements for many sites because the recipe data is still on the page for crawlers even if it’s not rendered for a normal visitor.



  • Really interesting! I wonder what would happen if you combine these two properties. Suppose some length of the middle is all walls, and the hooks are infill, or vice versa. Is there an optimal mix that maximizes the weight it can support in your testing, or have you found the optimal configuration (with infill along the entire length) already?





  • I disagree. You should have validation at each layer, as it’s easier to handle bad inputs and errors the earlier they are caught.

    It’s especially important in this case with email because often one or more of the following comes into play when you’re dealing with an email input:

    • You’re doing more than sending an email (for ex, creating a record for a new user).
    • The UI isn’t waiting for you to send that email (for ex, it’s handled through a queue or some other background process).
    • The API call to send an email has a cost (both time and money).
    • You have multiple email recipients (better hope that external API error tells you which one failed).

    I’m not suggesting that validation of an email should attempt to be exhaustive, but a well thought-out implementation validates all user inputs. Even the underlying API in this example is validating the email you give it before trying to send an email through its own underlying API.

    Passing obvious garbage inputs down is just bad practice.






  • Download Bambu Studio and slice some multi material prints. The preview tells you how much filament will be purged. There are several settings and model characteristics that will affect the purged volume.

    Flushing volume: this directly controls the volume purged while swapping between any two filaments. Darker to lighter colors will need a higher flushing volume. You’ll also need a higher flushing volume when changing materials.

    Purge to infill: this reduces the purged volume by accounting for the volume that can be printed as infill before reaching perimeters. It’s not very effective for smaller models because there is just less infill area.

    Printing multiple copies: this reduces the ratio of waste to printed parts, since for each layer you’ll need the same number of filament swaps.

    Part orientation: often the part orientation will have a dramatic effect on the number of filament swaps. Imagine a blue cube with a red face. This can be optimized to one color swap if the red face is horizontal instead of vertical.

    Print sequentially: For multiple parts on the plate, grouping them by color similarity and printing groups sequentially can reduce the number of swaps. Imagine two blue parts and two red parts on the same plate. This can be optimized to one color swap for the entire print instead of one swap per layer.

    In my experience, the waste for average complexity multicolor prints is similar in scale to supports, and is easily offset if you’re upgrading from a less reliable printer. Failed prints are filament waste too.