284 karma · joined November 30, 2012
It's already in use in several places (e.g., https://www.mintlify.com/docs/ai/skillmd#skills-discovery-en...) and is supported by `npx skills add`.
Do the runes make it smarter or just run faster (or both)?
- https://community.openai.com/t/skills-for-codex-experimental...
- https://developers.openai.com/codex/skills/
I would love more information about this feature! Bad line-wrapping is the reason I loathe Prettier.
There are a few proposals floating around, but one issue is that you don't always know whether a task will be long-running, so having separate APIs for long-running tasks vs "regular" tool calls doesn't fully address the problem.
I've written a proposal to solve the problem in a more holistic way: https://github.com/modelcontextprotocol/modelcontextprotocol...
One thing I would like to see more focus on in React is returning components from server functions. Right now, using server functions for data fetching is discouraged, but I think it has some compelling use cases. It is especially useful when you have components that need to fetch data dynamically, but you don't want the fetch / data tied to the URL, as it would be with a typical server component. For example, when fetching suggestions for a typeahead text input.
(Self-promotion) I prototyped an API for consuming such components in an idiomatic way: https://github.com/jonathanhefner/next-remote-components. You can see a demo: https://next-remote-components.vercel.app/.
To prove the idea is viable beyond Next.js, I also ported it to the Waku framework (https://github.com/jonathanhefner/twofold-remote-components) and the Twofold framework (https://github.com/jonathanhefner/twofold-remote-components).
I would love to see something like it integrated into React proper.
I recently added some benchmarks to the TechEmpower Web Framework Benchmarks suite, and Next.js ranked near dead last, even for simple JSON API endpoint (i.e. no React SSR involved): https://www.techempower.com/benchmarks/#section=data-r23&hw=...
I discussed it with a couple of Next.js maintainers (https://github.com/vercel/next.js/discussions/75930), and they indicated that it's only a problem for "standalone" deployments (i.e. not on Vercel). However, I'm not entirely convinced that is true. I wonder if there are major optimizations that could be made to, for example, the routing system.
In any case, I'm excited!
https://api.rubyonrails.org/v7.1/classes/ActiveSupport/Cache...
So the final code from the article would look like:
class ProductSearch < TalentScout::ModelSearch
criteria(:search) { |search| where("title ILIKE '%?%'", search) }
criteria(:from_price) { |from_price| where("price > ?", from_price) }
criteria(:to_price) { |to_price| where("price < ?", to_price) }
criteria(:properties) { |properties| joins(:product_properties).where(property_id: properties) }
criteria(:category_id) { |category_id| where(category_id: category_id) }
order :price, default: :desc
end
1) `from_price` will silently never be applied
2) `sort_type` and `sort_direction` defaults are mixed up and always nil, either of which will raise an exception, but only when the corresponding request params are omitted
Another benefit of using the gem: instances of the `ProductSearch` class from above can be used with the stock Rails form builder (i.e. `form_for` and `form_with model:`).
Here's an example, assuming there are 200 rows in total:
- User visits page; first 10 rows are listed.
- User clicks "More" link; next 20 rows are fetched via Ajax and appended to the list (30 total).
- User clicks "More" link again; next 30 rows are fetched via Ajax and appended to the list (60 total).
- User clicks "More" link again; browser navigates to the next 60 rows (rows #61-120).
- User clicks "More" link again; browser navigates to the next 60 rows (rows #121-180).
- User clicks "More" link again; browser navigates to the final 20 rows (rows #181-200).
The basic idea is that there are two typical use cases: 1) The user expects their desired row to appear in the first few dozen rows, and will change their query if it doesn't (as mentioned in the article). 2) Or, the user really does want to sift through all the rows, in which case it's preferable to do it in large steps.
Of course, the Ajax fetch increments can be tuned to best support these cases, as well as the number of Ajax fetches before triggering a full page transition.
I actually wrote a Rails gem that encapsulates this behavior, including robust handling of back-and-forth navigation: https://github.com/jonathanhefner/moar
Additionally, you might create an SJR[2] template which injects the rating directly into the page, possibly avoiding the need for a separate gem.
[1] https://www.youtube.com/watch?v=HctYHe-YjnE
[2] https://signalvnoise.com/posts/3697-server-generated-javascr...
I presume you've seen https://archive.org/details/softwarelibrary_msdos_games
As such, it is actually "Bane's Rule" which states, "you don't understand a distributed computing problem until you can get it to fit on a single machine first."
(Thanks to nekopa, who also referenced it further down in this thread.)