はてなブックマーク

この記事は、11月21日開催予定 第170回 PHP勉強会＠東京 （ハッシュタグは #phpstudy ）のメイントーク資料、およびその補足ポエムです。イベント開催の前日に、この文章を書いています。 トーク資料: PHP 8.4 新機能紹介PHPドキュメントの現状類を見ない量の機能が追加されたPHP 8.4だが、マニュアルが整備されないと使う人は限られる。だが、その執筆状況は、原文の英語、翻訳の日本語、共に厳しい。PHPやそのドキュメントも他のOSS同様、活動量の多い小数のコントリビューターに依存している状況だ。 メジャーバージョンアップの前後は特に大変になる。原文がリリース直前の完成となるため、追随する日本語訳のスケジュールは非常にタイトだ。そして、今年は例年になく厳しい状況と耳に入ってきた: 日本語ドキュメントへの貢献PHP 8.4には自分が作った新機能も入っている。それらのマニュアル

この記事は、6月28日開催予定 PHPer Tea Night #18 - 技術書オススメバトル への参戦エントリです。 Gポリア著「いかにして問題をとくか」 およそ80年前、「数学」という分野より、この本は出版された。 そして今に至るまで、数学に留まらないあらゆる分野の課題解決本として参照され続けている。 ソフトウェアエンジニアリングの世界でも評価は高い。元よりエンジニアは、あらゆる問題や課題を、抽象化、汎化、定量化、そして言語化することも生業としている。それをポリアはこの本の中で、「数学」という例題を通じて汎用的にやってのけた。 ここで言う「問題」とは特定の数学問題を指しているわけではない。数学に限らない、私達が出会ったことのない「未知の問題」を指している。 従って、私達エンジニアは、この本の表題を次のように読み替える。 「いかにして課題を解決するか」 『いかにして問題をとくか』｜丸善

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

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