Interesting read. As an indie puzzle dev (shameless plug: https://thinky.gg), I find the biggest leap happens when a system’s rules are rich enough that solving becomes about understanding the space and recombining elements, not memorizing solutions. Games with extensible grids and turn mechanics reward that kind of play and creation much better than static collections of challenges
It can be challenging but the large majority of skin cancers are fairly obvious and the main reason people don't spot them is because they are not checking their skin regularly and don't have any idea what to look for. Hopefully this app will help patients to learn the basic things to look for.
Been using cursors background agents to do this via mobile app. I was expecting a mobile app by anthropic by now. Wonder what will happen to this project when that happens?
Really cool, I actually haven't met many people using cursor background agents. I do think Anthropic is working on a web app for Claude Code (saw it in some thread somewhere), so I'm sure they're also working on a mobile app. In that case, the value for Omnara + Claude Code diminishes, but we're able to support any agent, so if every company has their own app, but a user can use all the same agents from a single platform, hopefully they'll choose the single platform.
Met my current best friend 15 years ago at Georgia Tech. He was a Fulbright scholar from Turkey studying architecture. Really glad this program existed!
This is very true. Over my 15 years of engineering, I have never suffered_that_ much with integrating with an api (assuming it exists). So the lack of "HATEOaS" hasn't even been noticable for me. As long as they get most of the 400 status codes right (specifically 200, 401, 403, 429) I usually have no issuss integrating and don't even notice that they don't have some "discoverable api". As long as I can get the data I need or can make the update I need I am fine.
I think good rest api design is more a service for the engineer than the client.
> As long as they get most of the 400 status codes right (specifically 200, 401, 403, 429)
A client had build an API that would return 200 on broken requests. We pointed it out and asked if maybe it could return 500, to make monitoring easier. Sure thing, next version "Http 200 - 500", they just wrote 500 in the message body, return remained 200.
I just consumed an API where errors were marked with a "success": false field.
The "success" is never true. If it's successful, it's not there. Also, a few endpoints return 500 instead, because of course they do. Oh, and one returns nothing on error and data on success, because, again, of course it does.
Anyway, if you want a clearer symptom that your development stack is shit and has way too much accidental complexity, there isn't any.
This is the real world. You just deal with it (at least I do) because fighting it is more work and at the end of the day the boss wants the project done.
Ive seen this a few times in the past but for a different reason. What would happen in these cases was that internally there’d be some cascade of calls to microservices that all get collected. In the most egregious examples it’s just some proxy call wrapping the “real” response.
So it becomes entirely possible to get a 200 from the thing responding g to you but it may be wrapping an upstream error that gave it a 500.
I've had frontend devs ask for this, because it was "easier" to handle everything in the same then callback. They wanted me to put ANY error stuff as a payload in the response.
> So the lack of "HATEOaS" hasn't even been noticable for me.
I think HATEOAS tackles problems such as API versioning, service discovery, and state management in thin clients. API versioning is trivial to manage with sound API Management policies, and the remaining problems aren't really experienced by anyone. So you end up having to go way out of your way to benefit from HATEOAS, and you require more complexity both on clients and services.
In the end it's a solution searching for problems, and no one has those problems.
>> If you move user posts to another server, the href changes, nothing else does
It isn't clear what insurance you are really buying here. You can't possibly mean another physical server. Obviously that happens all the time with any site but no one is changing links to point to the actual hardware - just use a normal load balancer. Is it domain name change insurance? That doesn't add up either.
>> If suddenly a bug is found that lets people iterate through users that aren't them, you can encrypt the url, but nothing else changes.
Normally you would just fix the problem instead of doing weird application level encryption stuff.
>> The bane of the life of backend developers is frontend developers that do dumb "URL construction" which assumes that the URL format never changes
If those "frontend" developers are paying customers as in the case of AWS, OpenAI, Anthropic then you probably want to make your API as simple as possible for them to understand.
reply