masakielastic

ココナラブログの記事作成における評価基準

1. 誰のどんな詰まりを扱っているかが明確か

記事の冒頭や前半で、

• どんな人に向けた記事か

• どんな段階の困りごとか

masakielastic

あなたは技術記事ライターです。 次の条件に従って、日本語で「開発者向けの対話形式記事」を作成してください。

---

記事テーマ

[ここに記事テーマを書く]

---

masakielastic

PHP RFC の英文レビューと改稿を手伝ってください。対象は UTF-8 の code-point traversal を扱う str_iter() RFC です。レビュー方針と文章スタイルは次のとおりです。

目的

• 小規模 RFC として、論点を増やしすぎず、仕様の境界を明確にする
• 「なぜ追加する必要があるのか」「誰にとって意味があるのか」を重視する
• 便利機能の寄せ集めではなく、shared primitive / building block という位置づけを明確にする
• validation や grapheme cluster のような隣接論点とは意図的に切り分ける

議論のスタイル

• まず節ごとの役割を明確にしてください

masakielastic

あなたは PHP RFC のレビューと構成整理を支援するアシスタントです。 今回の対象は、小規模だが論点の多い RFC です。目的は、仕様を増やすことではなく、設計判断・動機・スコープ・将来課題を適切な密度で整理することです。

以下の方針で応答してください。

【全体方針】

• PHP RFC は単なる仕様書ではなく、投票前に設計判断を共有する公開文書として扱う。
• 小規模 RFC では Proposal を主役にする。
• Proposal を読めば仕様の骨格が分かる状態を重視する。
• Introduction は必要なら短く置き、追加内容の宣言ではなく「争点設定・位置づけ」に使う。

masakielastic

Zig で embed PHP を利用する

構成

build.zig 
c
src/main.zig

実行

masakielastic

2026年版 新計画

PHP Built-in Server (sapi/cli/php_cli_server.c) 再設計計画

0. この計画の目的

この計画の目的は、php_cli_server.c を一気に全面改修することではなく、次の 3 つの将来課題に耐えられる構造へ段階的に変えることです。

1. http_parser 依存の緩和と将来の llhttp 移行準備

masakielastic

#include <php.h>
#include <Zend/zend_smart_str.h>
#include <sapi/embed/php_embed.h>
#include <main/php_streams.h>

static int run_min_client(void);

int main(int argc, char **argv)
{
    PHP_EMBED_START_BLOCK(argc, argv)

masakielastic

#include <php.h>
#include <Zend/zend_smart_str.h>
#include <sapi/embed/php_embed.h>

#define SERVER_ADDR "tls://127.0.0.1:8443"
#define SERVER_CERT_PEM "localhost.pem"
#define SERVER_KEY_PEM "localhost-key.pem"

static int run_min_server(void);
static php_stream_context *create_tls_server_context(void);

masakielastic

#include <php.h>
#include <Zend/zend_smart_str.h>
#include <sapi/embed/php_embed.h>

static int run_min_server(void);

int main(int argc, char **argv)
{
    PHP_EMBED_START_BLOCK(argc, argv)

masakielastic

PHP RFC の書き方・議論スタイル共有メモ

概要

このメモは、今回の FILTER_VALIDATE_STRLEN RFC 検討を通じて整理した、PHP RFC の書き方と議論の進め方の実践メモである。目的は、他のチャットや今後の RFC 作成で再利用できる形で、論点設定・文章構成・FAQ 設計・スコープ管理の勘所を共有することにある。

---

1. PHP RFC は「仕様書」だけではなく「公開討論のための設計文書」

PHP RFC は、単に機能仕様を列挙する文書ではない。