koriym

Google Gemini

BEAR.Sunday：静寂と力強さを兼ね備えた、API開発のためのフレームワーク

静寂

喧騒を排し、静寂に耳を澄ませば、微かな音にさえも意識が向かう。それは、繊細なニュアンスや奥深い真理を捉えるための感性を研ぎ澄ます契機となる。

BEAR.Sundayは、複雑な技術をシンプルに、洗練されたコードを静かに紡ぎ出すフレームワークです。過剰な装飾を排し、本質に迫ることで、開発者の創造性を解き放ち、真の価値を生み出すお手伝いをします。

koriym

BEAR.Sundayとは

BEAR.Sundayは、オブジェクト指向のパワーとRESTの制約を融合させたPHPのフレームワークです。クリーンなオブジェクト指向設計と、Webの基本原則に沿ったリソース指向アーキテクチャを組み合わせることで、シンプルでありながら柔軟性と拡張性に優れたWebアプリケーションの開発を可能にします。

BEAR.Sundayの中核をなすのは、依存性の注入（DI）、アスペクト指向プログラミング（AOP）、リソース指向アーキテクチャ（ROA）の3つのフレームワークです。これらのフレームワークは互いに連携し、一貫性のある設計原則を提供することで、開発者がビジネスロジックに集中できる環境を整えます。

DIとAOPにより、オブジェクト間の依存関係を適切に管理し、モジュール化された再利用可能なコンポーネントを作成できます。ROAによって、アプリケーションの情報や機能をリソースとして表現し、統一的なインターフェースでアクセスすることができます。これは、Webとの親和性が高く、スケーラブルで疎結合なアーキテクチャを実現します。

また、BEAR.Sundayはフレームワークとライブラリの役割を明確に分離し、開発者がプロジェクトに最適なライブラリを自由に選択できるようにしています。これにより、フレームワークのコアをスリムに保ちつつ、常に最新のベストプラクティスを取り入れることができます。

koriym

SQLとORM: AIの時代における選択

SQLの利点

• シンプルで高速
• 柔軟性が高く、複雑なクエリにも対応
• AIとの親和性が高い

ORMとの比較

• SQLはORMよりオーバーヘッドが少ない
• SQLはデータベース固有の機能を直接活用できる

koriym

なるほど、元のイントロダクションに問題があるとのことですね。それでは、BEAR.Sundayの特徴を中心に、イントロダクションを全面的に書き直してみましょう。

BEAR.Sundayとは

BEAR.SundayはPHPのWebアプリケーションフレームワークです。BEAR.Sundayの目標は、クリーンアーキテクチャに基づいた高品質で保守性の高いRESTfulアプリケーションの開発を支援することです。

特徴

koriym

イベント駆動コンテンツ - Deep Dive (オリジナルプロポーザル)

さる、3/9に東京のPHPerkaigiというカンファレンスで「Webアプリケーションの効率を再定義するBEAR.Sundayの分散キャッシングフレームワーク」と題してモダンCDNを中心とする理想的な分散Webシステムのトークを行いました。それに対して「ゾクゾクした、自分の原点を考えさせられた、とてつもない伝説だった、映画のようだった」など従来のトークの感想に収まらないエモーショナルな感想が寄せられました。

これは、私のプレゼンテーションが "単なる技術的知識の伝達を超えて、聴衆の心に火をつける「体験」だったことを物語っています。技術的な学びは当然ありつつも、それ以上に開発者としての情熱や価値観に訴えかける内容だったからこそ、これほど多様な反響が寄せられたのだと思います。" （..以上トーク内容と感想を読んだAIの考察）

そこで、この体験を可能にしたプレゼンテーションの制作プロセス自体も、また違う物語として成立するのではないかと考えました。

本プレゼンテーションでは、元のスライドを用いて、「キャッシングという具体的な技術的課題への取り組みが、いかにして普遍的な問いかけと開発者としての情熱につながっていったのか」を、メイキング形式で語ります。松尾芭蕉の不易流行思想との邂逅、比喩と例え話による技術的概念の平易な説明、映画的な構成による聴衆の興味の喚起、聴衆の心に響く言葉選びと表現の工夫など、プレゼンテーション作りの舞台裏をベースにしながら、自分たちが誰のために何を作っているのかを訴えます。

koriym

# usage: . ~/.phpv php_version

export PATH="/opt/homebrew/opt/php@$1/bin/:$PATH"; php -v

koriym

<?php

namespace Application;

$fileName = '/not-writable';

// Human-only readable exceptions
// throw new \RuntimeException("{$fileName} is not writable.");

// Semantic exceptions

koriym

<?xml version="1.0" encoding="UTF-8"?>
<alps
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="https://alps-io.github.io/schemas/alps.xsd">
    <title>ALPS3min</title>

    <!-- Ontology -->
    <descriptor id="name" />

    <!-- Taxonomy -->

koriym

なぜ PageリソースとAppリソースがあるのか

どこから来たのか

BEAR.Sunday以前のフレームワーク、BEAR.Saturdayがページとリソースというレイヤーを持っていました。

https://blog.excite.co.jp/exdev/25879834/

MVCでいうとコントローラーの役割が"ページ"。ページクラスはコントローラーと違ってルーターによるメソッドのマッピングは必要なく、HTTPメソッドにマップするメソッドがありました。

koriym

<?php
if (PHP_VERSION_ID >= 80100) {
    set_error_handler(static function (int $errno, string $errstr, string $errfile) {
        return $errno === E_DEPRECATED && str_contains($errfile, dirname(__DIR__) . '/vendor');
    });
}