Since coding with Cursor, I’ve spent a lot of time thinking about how much computing interfaces have changed in such a short period of time.
Just as we saw a paradigm shift from imperative to declarative interfaces, LLMs have opened the door to new kinds of interfaces.
Intent-driven interfaces are already everywhere - from AI assistants processing raw data, to Arazzo for defining how APIs map to human-scale workflows, to agents capable of handling complex tasks.
While the doomer view is “robots will take all our jobs”, my optimistic take is we finally have a human-centric way of interacting with machines and it’s going to supercharge our abilities
I built Lttrs.co to make it easy to publish content to the web. From personal websites, to that pesky terms of service you need hosted for launching your iOS app. All your content is one-way synced from Google Docs so there's a clear source-of-truth (No more copy-pasting!). After you share your folder and hit publish, Lttrs builds an optimized, statically generated site (with a perfect 100 Lighthouse score for performance).
It's still early and I'd love to hear what you think!
From cursory googling it looks common for programs to expect you to work right up to the legal limit (80 hours/week based on 4-week averages) during residency. Having 16 hour days for ~7-8 years means that you probably have to get used to being a bit sleep deprived all the time.
A possible explanation could be based on research suggesting that regular lack of deep sleep increases risk of Alzheimer’s. Given that Neurosurgeons have a grueling 7-8? year residency period after medical school, it would be possible that they undersleep far more than the control group.
I would like to see how the prevalence of Alzheimer's among Neurosurgeons compares against a population with similar work/sleep schedules (eg. finance)
I think this is a bit cherrypicked. The example you're using is a fully qualified bound function. OData support for actions and functions explicitly exist to provide affordances for how to do RPC within OData. You can easily model this API in OData without requiring a function (eg. having a navigation property reference called "favoriteAirline"). Moreover, you can typically invoke functions without a fully qualified prefix (save cases where there is ambiguity).
For the most part, OData does a good job at letting folks opt into complexity, allowing integrators to make full use of APIs without needing to know anything about $metadata, inheritance mechanics, functions, etc.
This looks a lot like OData - a REST-ful API standard with schema introspection, patterns for defining and traversing resource relationships, well-defined guidance around mechanics, tooling support. In particular, the "Microtypes" concept resembles how entities work in OData - rich query support for collections (eg. sorts, filters, order by), "expansions" on related resources, even inheritance semantics (ie. being able to request a derived entity as its parent type).
I hear you. This was a fun project to adapt an existing standard (OData) to be compatible with GraphQL and get a sense of what that looks like over a really big API (hundreds of types, thousands of facets). Part of this is also to see whether as a developer, it makes integrating with Microsoft Graph easier or faster. I'd love to hear your thoughts.
I built this demo during Microsoft's internal hackathon, Oneweek, to show what GraphQL querying of the Microsoft Graph API could look like. While not all GraphQL functionality is currently implemented (namely support for pagination, data mutations), I think it's quite cool to be able to request resources from different services in a single request (eg. fetching my recent emails, OneDrive files, users in my org). The gist of how this works: the tooling translates an OData schema into a GraphQL schema and code generates resolvers for each field.
Yes, and in case there's confusion around Core vs. Standard. Standard can be thought of a spec, and supporting a version of .NET Standard implies support in a specific set of versions of .NET Core.
It's recommended to access AAD through the Microsoft Graph API (as opposed to the AAD Graph API) unless it is one of the few scenarios not yet supported on Microsoft Graph. There is a lot of investment in adding new functionality to Microsoft Graph (such as the ability to extend AAD entities with custom, persisted properties on the /beta/ endpoint) and tooling. You can try/prototype out a bunch of your AAD requests in the Graph Explorer without writing code/needing to authenticate for most calls:
In a previous Theranos thread, someone made the comment that there are dangers to allowing consumers to access tests and test data without interpretation or prescription by a doctor. Results can be misleading without context and could lead to rash and adverse health decisions. Not sure if I agree 100%, but it seems like a valid concern.
Just as we saw a paradigm shift from imperative to declarative interfaces, LLMs have opened the door to new kinds of interfaces.
Intent-driven interfaces are already everywhere - from AI assistants processing raw data, to Arazzo for defining how APIs map to human-scale workflows, to agents capable of handling complex tasks.
While the doomer view is “robots will take all our jobs”, my optimistic take is we finally have a human-centric way of interacting with machines and it’s going to supercharge our abilities