// Before $payload = json_encode($response); $data = json_decode($input, true); $ok = json_validate($input); // After $payload = fastjson_encode($response); $data = fastjson_decode($input, true); $ok = fastjson_validate($input); That's the migration. Search-and-replace json_* for fastjson_*. JSON flags, error constants, and last-error semantics carry across byte-for-byte. The two extensions sit next to each other in the same process; adoption is per call site, not per repo. On the simdjson_php canonical 14.8 MB corpus, that swap buys 6.06× encode throughput, 2.66× decode, and 5.10× validate against ext/json on the same PHP 8.6.0-dev build. The repo is at github.com/iliaal/fastjson. 0.3.0 shipped yesterday. Why drop in faster JSON for PHP ext/json is fine. It's correct, well-maintained, and tracks the spec. On low-traffic endpoints it isn't on anyone's profiler. The cost shows up at scale: any application that calls json_encode and json_decode on every request path eventua...

(new FastChart\StockChart()) ->setSize(1200, 600) ->setTitle('AAPL last 90 days') ->setTheme(FastChart\Chart::THEME_DARK) ->setOhlcv($ohlcvRows) ->setMovingAverages([20, 50, 200]) ->setVolumePane(true) ->setCandleStyle(FastChart\Chart::STYLE_HOLLOW) ->renderToFile('/tmp/aapl.png'); That's a server-side OHLCV candlestick chart with three moving averages, a volume pane, and a hollow candle style. Roughly 68 ms on a single core at 1920×1080. No microservice, no Node sidecar, no JavaScript runtime. PHP, gd, fastchart. fastchart 0.2.0 shipped two days ago. 19 chart types behind a fluent OO API, plus a Symbol family (Code 128 barcodes and QR codes) that landed in this release. The repo is at github.com/iliaal/fastchart. Why charts in PHP again Twenty years ago, Rasmus and I shipped the initial release of PECL/GDChart in January 2006. It wrapped Bruce Verderaime's gdchart C library from users.fred.net/brv/chart/. The PECL page is still up at https://pecl.php.net/package/GD...

The launch post for php_clickhouse 0.6.0 covered the framing: native binary protocol, soft fork of the stalled SeasClick, modern ClickHouse types, 30-40% faster than HTTP at high throughput. That post landed April 25, 2026. Today (May 1, 2026) the current tag is 0.8.1, and I'm calling the extension stable. The six days in between were a focused quality cycle, not a feature sprint. Three buckets: Performance. Insert and write paths build native ClickHouse columns one at a time directly from row-major input. Peak intermediate PHP memory dropped from N_rows × N_cols zvals to one column. Security. Strict full-consumption parsers across Map, narrow-int, Int128 / UInt128, geo, DateTime64, Time64, hex literals, and typed parameters. Wrong-type input throws instead of corrupting memory or coercing silently to zero. Recursive type-conversion gained a depth cap so adversarial server schemas can't blow the stack. Stability. Per-Client state moved from file-scope std::map banks onto the zend_object...

Anyone who's tried AI-assisted trading research has hit the same wall. The agent has no native access to your charts. You end up copy-pasting symbols, indicator values, screenshots, and Pine Script back and forth between TradingView and Claude or Cursor. The tools that try to fix this fall into two camps: route market data through a third-party API (added latency, added cost, their interpretation of your bars), or pollute your TradingView chart with helper indicators just so an agent can read them back. There's a third path that's more obvious in retrospect: drive your local TradingView Desktop through the Chrome DevTools Protocol that the app already exposes on port 9222 when you launch it with --remote-debugging-port=9222. The agent talks to the same TradingView you already use, reads what your chart actually shows, executes Pine Script through TradingView's own runtime. Same data, same indicators, same features, just with an agent in the loop. A project called tradesdontlie/tradingview-mcp star...

In 2005 I wrote a PHP binding for libstatgrab and pushed it to PECL. The extension took CPU, memory, disk I/O, network, process, and user statistics from a cross-platform C library and exposed them to PHP as plain functions. I moved on to other things, libstatgrab kept evolving, PHP went through three major versions, and the binding sat untouched. By 2020 you could not build it against PHP 7 without patches. By PHP 8 it was effectively gone. statgrab 2.0 brings it back. PHP 8.0 through 8.5, libstatgrab 0.92+, glibc Linux, musl, macOS, FreeBSD. The 2006 procedural API still works (sg_cpu_percent_usage, sg_memory_stats, sg_diskio_stats), there is a modern OO surface (Statgrab::cpu(), Statgrab::memory(), Statgrab::processes()), counters return as 64-bit int instead of the 2006 stringified %lld, and the BC bugs that were latent in the original (swapped page-stat keys, copy-pasted gid/egid fields, the flat name_list for users) are fixed. A few things had to change to get there. One of them wa...