はてなブックマーク

はじめに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」までは良くても、その設定により各所の振る舞いがどう変わるのか、これを正確に説明できる人は意外と少ない気がします。 このトークでは「どこで設定されているか？」「何が設定されているか？」に対する注意喚起に加え、実装上の具体的なベストプラク

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