はじめにLaravel 11の新機能に 合理化したアプリケーション構造 “Streamlined Application Structure” というものがある: Laravel 11では、既存のアプリケーションに変更を加えることなく、新しいLaravelアプリケーション向けに合理化したアプリケーション構造を導入しました。新しいアプリケーション構造は、Laravel開発者がすでに慣れ親しんでいるコンセプトの多くを保持しながら、よりスリムでモダンなエクスペリエンスを提供することを目的としています。 https://readouble.com/laravel/11.x/ja/releases.html#structure 該当プルリクエスト で Slim skeleton と題されている通り、初期構造が大幅に簡略化されている。 一方、既存のアプリケーションをアップグレードする場合: Larav

PHPerKaigi 2024の感想です。同じ内容をforteeのフォードバックコーナーへも投稿しています。 同じトークに対して他人がどう感じたか、これもまた学びの糧になると感じているため、自分の感想を投稿しています。順序はトークの実施順です。 雰囲気実装を少し抜け出そう！RFCからPHPの実装までを考えるタイムゾーンとサマータイム！！！ / @suguru_ohki / 資料メッセージに対するテーマの選定が良かったと思います。 雰囲気で実装しない、あらゆる実装において大切なことですが、何故かタイムゾーンでは皆がそれをやってしまいがちです。「とりあえずJST」までは良くても、その設定により各所の振る舞いがどう変わるのか、これを正確に説明できる人は意外と少ない気がします。 このトークでは「どこで設定されているか？」「何が設定されているか？」に対する注意喚起に加え、実装上の具体的なベストプラク

PHPerKaigi 2024 レギュラートーク資料です。 スライド版とテキスト版は全く同じ内容です。トークとしてご覧頂く場合はスライド版を、資料中のリンクやコードを確認される場合はテキスト版をご覧ください。 スライド版テキスト版プロポーザルスキーマ駆動開発は非常に強力な開発手法です。 API仕様とサーバ実装が確実に一致し、クライアントライブラリは自動生成されます。フロントエンドは型システムの力により、「サーバ」を意識せずに開発が可能です。「APIの繋ぎ込み」タスクや結合テスト時の問題切り分けが不要になります。なるほど、完璧な作戦っスね―――ッ 不可能だという点に目をつぶればよぉ～ スキーマ駆動開発はしばしば「辛い」と言われます。 スキーマと実装とをそれぞれ書かなければいけません。開発中の変更がフロントエンドのCIを予期せず壊すことがあります。破壊的変更を避けるために類似のエンドポイントが

Laravel用パッケージ Laravel OpenAPI Validator をバージョン1.0.0としpackagistへ公開した。 GitHub - KentarouTakeda/laravel-openapi-validator: Request and response validators based on the OpenAPI Specification.Request and response validators based on the OpenAPI Specification. - KentarouTakeda/laravel-openapi-validatorこの記事では、1.0.0時点での機能の紹介と共に、それぞれの機能の実装意図や設計思想に簡単に触れたい。 概要OpenAPIドキュメントによるリクエストやレスポンスのバリデーションを行うLaravelパッケー

1月29日開催予定 PHPer Tea Night #15 - Laravel11直前回 で発表予定のLT資料、及びその解説記事。 LT資料紹介した機能クラスベースの追加バリデーション追加バリデーションの記述方法が拡張された。 これまでは FormRequest へ withValidator($validator) を実装しバリデータに対し $validator->after(function(){ ... }) でクロージャを登録する方法だった。 これはお世辞にも書きやすいと言えない。今回、新たに次のような書き方が可能となった。 FormRequestに新設された after() を実装。バリデーションに必要な依存をメソッドインジェクションで取得可能。after() からは追加バリデーションを行うオブジェクトを配列で返却。追加バリデータはinvokableなオブジェクトなら何でも良い。

Hexoで作成したブログ記事にreveal.jsのスライドを埋め込むプラグインHexo Reveal Embedを作成し公開した。作成の動機やライブラリの紹介を記事にしたい。 インストール・設定せっかくなので、実際にプラグインを使い埋め込みスライドとしてインストール方法や設定を紹介する。 作成動機巷には SlideShare や Speaker Deck と言ったサービスが既に存在する。埋め込み表示にももちろん対応している。 だが以前より、これらのサービスは使わず、何とかして自分のブログに直接スライドを埋め込みたいと考えていた。 理由は主に「コンテンツの所有者」「執筆環境の統合」の2点だ。 コンテンツの所有者要はSEOスコアが欲しい。 QiitaやZennを使わず独自ドメインで謹製のブログを運営しているのは単なる趣味だ。そして、この趣味のおかげで、大手サービスの強大なSEOスコアに対して無

「このLaravelとあのLaravel、全く別物じゃないか。」 Laravelは自由度が高い。Eloquentなどハイレベルな機能も提供されているが低レイヤーのAPIも存在し実装クラスの配置にも制限はほぼ無い。これら自由度のおかげで他フレームワーク経験者もスムーズにLaravelに入門できる一方、現場でしばしば聞かれるのが冒頭に挙げた声だ。 自由度は重要だが状況（プロジェクトの規模や背景）をある程度固定した上でのルール導入もまた有用と考え、今回は 小中規模の案件 を対象に Laravelを使い倒す という観点で規約を作成した。 小中規模のみ想定。設計のレイヤー化が生産性を大きく左右するような規模は想定しない。 （この想定を超えるプロジェクトはそもそもLaravelを採用すべきでない） フレームワークへのロックイン防止も考慮しない。 （小中規模であれば、ここにコストを払うより必要に応じ使い

追記: 2022/8/2 22:00公開後、本文中（引用部分を除く）の「リレーショナルモデル」という用語の使い方に誤りがある旨のご意見をTwitterで多く拝見しました。それを受け記事タイトルを含む幾つかの箇所を修正しました。ご指摘下さった皆様、有益な議論や情報交換に参加されていた皆様、本当にありがとうございました。修正履歴は こちら 。 TL;DR「モデリング」と呼ばれる取り組みの多くは、決してエンジニアだけのためのものではない。特に「ERモデル」「ER図」は、あらゆる開発工程や開発以外も含む広い分野で大いに役立つ。開発に携わる誰しも、「ER図」を通じて知見を共有してみよう。問題意識や課題、モデリング（特に論理データモデル）の知識やER図の作図は何を解決してくれるのか、本記事ではこれらを簡単なER図の読み方を交え解説していく。 自然言語で要件を共有する難しさ例えばこんな要件があったとする

PHPerKaigi 2023感想。fortee より登壇者の方へ送ったフィードバックと同じ内容。他の方のブログなどを読み、同じ登壇に対し他人がどのような感想を持ったかを知るのも学びの機会になると気づきでは自分の分もブログにも掲載することにしました。いえ、単にフィードバックとブログを別で書く時間がないだけです。 今回は登壇もさせて頂いたので、そのレポートや余談、解説しきれなかった内容などを近日中に別の記事として掲載する予定です。 名著「パーフェクトPHP」のPart3に出てきたフレームワークを令和5年に書き直したらどんな感じですかね？ @o0h_後輩に是非とも聞かせたいと感じる非常に価値のあるトークでした。ありがとうございました。 まずは歴史や（過去の）仕様の話をし、それらと最新仕様とを比較した上でいざ実装という流れだったので、それぞれ何を目的に実装されているのかなどが必然的に示されていた