jonathanhefner

Runing GLM-5.2 on local hardware

Do the runes make it smarter or just run faster (or both)?

Thank you for sharing! Based on your experience, do you think a two-model system might fare better? For example, two models in serial where the second model is trained to "sniff out" potential hallucinations and fact check them (and possibly iterate with the first model)?

Does anyone know why there hasn’t been more widespread adoption of OpenAI’s Harmony format? Or will it just take another model generation to see adoption?

OpenAI has already adopted Agent Skills:

- https://community.openai.com/t/skills-for-codex-experimental...

- https://developers.openai.com/codex/skills/

- https://github.com/openai/skills

- https://x.com/embirico/status/2018415923930206718

And since AI agents are extremely good at using them, command-line tools are also probably 235x more effective for your data science needs.

Vite Format: "More flexible line-wrapping"

I would love more information about this feature! Bad line-wrapping is the reason I loathe Prettier.

I'm not familiar with Airflow, but MCP supports progress notifications: https://modelcontextprotocol.io/specification/2025-03-26/bas...

Long-running tasks are an open topic of discussion, and I think MCP intends to address it in the future.

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...

RSC is indeed very cool. It also serves as a superior serialization format compared to JSON. For example, it can roundtrip basic types such as `Date` and `Map` with no extra effort.

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 have also found that Next.js is shockingly slow.

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.

Agreed! There is a proposal for something like that in the WHATWG repo: https://github.com/whatwg/html/issues/8538

I would bet at least one person at Meta wanted to call it Llamapalooza.

In any case, I'm excited!

JavaScript is dead. Long live YavaScript.

Upcoming in Rails 7.1, you can specify a custom compressor for your cache, out of the box. See the `:compressor` option of `ActiveSupport::Cache::Store.new`:

https://api.rubyonrails.org/v7.1/classes/ActiveSupport/Cache...

Very cool bot! I was looking for that kind of bot a few months ago, but I couldn't find one that was still maintained, so I created my own[1]. But if you're going to continue maintaining yours (despite the FB debacle), I may just use yours instead.

[1] https://github.com/jonathanhefner/verba-sequentur

I created a gem which wraps all this up in a nice API: https://github.com/jonathanhefner/talent_scout

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:`).

I agree with most of the points regarding user experience. But I loathe infinite scrolling, and so strongly disagree that Facebook "got it right." I think "geared pagination" with a sprinkle of Ajax works well though, in lieu of infinite scrolling.

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

Disappointing... still no support for HTML5 date and time input types. Safari seems to be the last major hold out[0] keeping JavaScript-powered date pickers a (prudent) necessity.

[0] https://caniuse.com/#feat=input-datetime

My own site, intentionally brutalist: https://jonathan.hefner.pro/

Try this short video from SIGGRAPH 2007: https://www.youtube.com/watch?v=vIFCV2spKtg

I think there is a more Rails-y way to do this. Derek Prior gave an excellent talk[1] at the recent RailsConf. The TLDW is "all-REST all-the-time." Applying this principal to the example in the article, instead of adding a custom `movie_rating` action, you would create a `MovieRatingsController` with a `show` action.

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 like to imagine so! :D

I presume you've seen https://archive.org/details/softwarelibrary_msdos_games

I love the cleverness of old games and the tricks used to produce compelling effects on underpowered hardware.

I believe it's a reference to this old (but insightful) comment: https://news.ycombinator.com/item?id=8902739

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.)

I also found his research intriguing! Here is a nice write-up for anyone unfamiliar: http://www.mostlyodd.com/death-by-utopia/

I hadn't heard of fsql, but I did recently find q[1]. If anyone has experience with both, I'd be interested to hear if one does its job better than the other.

1: http://harelba.github.io/q/

At least two of these are available for free download (as in "not pirated"):

http://thinking-forth.sourceforge.net/

http://www.projectoberon.com/

If you liked this talk, or perhaps liked the topic but found the pacing a bit fast, here is a friendlier-paced revision of it presented at Strange Loop 2010: http://www.infoq.com/presentations/Thinking-Parallel-Program...

Also chiming in: same thing happened to me, but they sent my account to collections without notifying me first.

When I was on the phone with the collections agent, I was very polite and told her I knew she was just doing her job. I then got her to admit that this sort of thing happens all the time with AT&T, and that a lot of her phone calls go the same way.

Since then I've suspected that AT&T's practices go beyond mere incompetence and into abusive territory.

I had the very same experience (though my use case was something akin to autocomplete), and so have a handful of other people I've spoken with. I think that has interesting implications regarding the patentability of software and algorithms.