loloquhwonedeo

"Switch workspaces faster than ever with the handy new Super + Alt + Scroll shortcut." that's going to suck for left-handed mouse users as "super" tends to not be accessible with the non-mouse hand on most compact keyboards.

despite what the article shows, YAML is NOT a programming language - constructs such as `if`, `when` and others are not generic. Try to feed an ansible playbook to Travis, or get those jinja-like variable substitutions working with a YAML parser that doesn't process them, and things won't work as expected.

Thanks for making my point with actual data :) (to restate: if the US pays 100K for this skillset, don't sell yourself cheap at 30K. Where you are only matters to local companies.)

"quality at a fraction of price compared to what they can get elsewhere." - not sure about this part. I moved from $LATAM_COUNTRY to $A_COUNTRY_NORTH_OF_MEXICO precisely because given my skill level, compensation was too low and my work too undervalued. Remote should leverage the playing field in the other direction: expect to be paid as well as you would if you lived in a more developed country. Insist on it. Don't undersell yourself.

Not really the first time Red Hat leaves users high and dry - also happened when they made Red Hat non-free with Fedora (then very unstable) as an alternative. I moved to Debian, never looked back, and today I regret it less than ever :)

It would be great if the API specification could be written once and then consumed by both server and clients, not only for functional validation as shown in the article but also for the server to use the spec to validate and serialize inputs/outputs.

As described, there is a disconnect where you went to all the work to create the openapi oas.yaml file, and can feed that to your test client to ensure the API responds to that, but the API still had to be coded by hand to comply with the spec.

A way to feed the oas.yaml code to flask-smorest somehow so it derives the endpoints and schemas from that (hey it already makes a ton of assumptions about how to structure the application, requiring e.g. a set of methods named exactly as the endpoints so they can be easily matched) would make it so the single oas.yaml file drives both ends of the implementation, would make coding work easier as the schema doesn't need to be described multiple times in multiple languages/formats, and would provide quick feedback (FAILURES) if I change the schema without coding the required endpoint support.