Laravel・Symfony をはじめとする PHP のフルスタックフレームワークの多くは、DI コンテナを提供しています。
もちろん、そのようなフレームワークを使わなくても、PHP の DI ライブラリ は OSS として利用できるものがたくさんあるため、適宜導入が可能です。
もはや我々にとってなくてはならぬ存在となった DI コンテナですが、みなさん一度は自分で作ってみたいと思ったことがあるのではないでしょうか?
このセッションでは、最低限、どのような要件を満たせば DI コンテナと言えるのか、PHP で広く知られる規約であるPSRの定義を起点に、各種フレームワーク・ライブラリの実装を追いかけながらなんちゃって DI コンテナの要件定義をやってみようと思います。
ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか?
実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。#
具体的なソフトウェアの実装における抽象レイヤーの話
「PHPは脆弱」
PHPerの方ならこの言葉一度は聞いたことがあるでしょう。
これなんでなんでしょうね〜〜!?!?!?わかるひとーーーー!!!!????
ということで、本トークでは「PHPは脆弱」と言われるようになった原因について以下のようなワードに触れつつ、歴史から振り返ってお話をします。
そして、その内容を踏まえ、我々は「どのようにプログラミングをしていけば、より安全なソフトウェアを開発していくことが出来るか」について自分なりに述べさせていただきます。
普段PHPを利用している方も、これから書いてみたいという方も楽しめるトークを目指します。
ソフトウェア開発を行っていると以下のような用語を見かけると思います
これらの用語に触れると、興味と好奇心を掻き立てられると思います。
いざ調べてみるとこれらの用語が具体的に何を意味するのか、どのように適用されるのかが分からなくて圧倒されます。
これらの用語の具体的な例や実践を通じて理解するのもいいですが、かなり数も多く時間がいくらあっても足りません。
特に〇〇アーキテクチャというものが色々な人々が語っていますが、具体的なイメージがつかず、気軽に試す事もままなりません。
そこで、一つ一つの用語を覚えるよりも体系的な理解を行っていくことが必要なのではないか?と考えています。
本トークではこれらの用語がどのように関連し合っているのか?どのように向き合っていけばいいのか?をお話いたします。
みなさんはシステムの設計を進めた後で、「こうしておけばよかった」と思う瞬間はありませんか?私はたくさんあります。
初めてテックリードとしてプロジェクトにアサインされ、技術選定やシステム設計を試行錯誤して進めました。
プロジェクト当初はうまくできたと感じていましたが、開発メンバーが増え、プロジェクト規模も大きくなり、振り返ると「こうすべきだった」と思う場面が増えてきました。
特に痛感したのは、技術選定やシステム設計といった基盤部分は、後からの変更が難しく、当時の判断がプロジェクト全体に大きな影響を与えることです。
本セッションでは、そんな経験を踏まえ「もしもう一度やり直せるならこうする」という視点で、以下の内容を中心にお話しします。
・テスト設計について
・アーキテクチャ設計について
・ドキュメント設計について
技術選定や設計に悩んでいる方にとって参考になる情報をお伝えします!
Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。
スクリプトがサーバ全体のメモリを食いつぶさないようにするための安全装置として、PHP にはプロセスごとのメモリ消費を memory_limit という設定値で制限できる仕組みがあり、制限を超えた時には "Allowed memory size of N bytes exhausted" というメッセージが出ます。
世には PHP 製の OSS が星の数ほどあり、GitHub を "Allowed memory size of" で検索すれば、そういった PHP 製の OSS プロジェクトでメモリ問題に悩まされているものを見つけられます。
それらを適当に拾い食いして辻斬りのように解決していく活動を通じ、PHPのメモリ問題の基本的な解決方法を紹介していきます。PHP の基本的なメモリ管理機構やメモリ消費量の計測方法、参照関係のたどり方、メモリを食いがちな部分といった話もあわせて解説します。