atheken @ atheken @programming.dev

Posts

0

Comments

103

Joined

2 yr. ago

Thanks, and you are basically correct on both counts:

• I supported an API that had a Batch endpoint that could be "partial success" -- and that was a mess.
• I have been experimenting with something where you have standardized elements because the Fetch API doesn't throw on 4XX/5XX, so having one if check, rather than two, makes sense.

At this point, it's an experiment.

Context is whatever makes sense to provide to a consumer to help them debug it or respond to it - the same basic idea as in the rfc under details. IMO, it can't easily be generalized. Some APIs may have context to provide, others may not. These could be validation errors in a structured format, or backoff timings in the case of a 429.

Success is something that you can sniff for after deserializing, as IIRC Fetch API will not throw except for a network errors, even in the event of a 4XX or 5XX.

Consider something like:if(!obj.error_code){} vs if(obj.success){ }. Certainly, you could consolidate the error_code and success member, but with the sloppy truthiness of testing in Javascript, including something like that as a standard part of all responses may make sense.

I quickly skimmed this, and it looks kinda overwrought to me.

This is the format I’ve been using:

    
{
success: bool
error_code: number,
message: “human-centric error message”,
context:  { optional, user-defined details }
}

  

I use miniflux, and you can configure it to modify feed items. As far as I know it does not purge anything by default.

Really, pulling an RSS feed and parsing it, storing stuff is probably 50 lines of bash, and less in a general purpose scripting language.

Breaking larger tasks down effectively removes uncertainty.

My general rule of thumb in planning is that any task that is estimated for longer than 1 day should be broken up.

Longer than one day communicates that the person doing the estimate knows it’s a large task, but not super clear about the details. It also puts a boundary around how long someone waits before trying to re-scope:

A task that was expected to take one week, but ends up going 2x is a slide of a week, but a task that is estimated at one day but takes 3x before re-scope is a loss of 2 days.

You can pick up one or two days, but probably not one or two weeks.

Are P1/P2 designations? If so, how in the world can those be correlated to time/workload?

I mean, the inverse is probably more productive. Specify the observable behaviors you want and let the “AI” build the software.

I shared the link partially because it’s a useful utility to check any public server TLS configs for vulnerabilities.

Here: https://www.ssllabs.com/ssltest/analyze.html?d=github.com

Prometheus has alerting and that’s really the preferred system for sending the alerts, IMO.