みなさん、バグ調査は好きですか?新人の頃にバグ調査がなかなか上手にできなくて手間取っている間に、ベテランの先輩が鮮やかにやりとげるのを見て、落ち込んだ経験のある人も多いと思います。
このトークではPHPer歴そろそろ18年の私の、バグ調査の時の目の付け所・思考過程を解説することで、バグ調査が苦手な方向けにやり方とコツをお伝えします。
PHPアプリケーションのコード品質を上げて、メンテナンス性をあげて、寿命を伸ばすためによく使われるようになったphpstan。
皆さんのプロジェクトのphpstanのlevelはいくつですか?baselineは解消できていますか?
SymfonyやLaravelで作ったアプリケーションに対してlevel:maxを設定してbaselineなし・エラーなしにした経験から、コードを書くときに気をつけること&phpstanを納得させるテクニックをLTの5分にギュッとまとめてお伝えします。
Laravelでアプリケーションを開発するとき、デフォルトORM(Object Relational Mapper)であるEloquent(Model)を使うことが多いと思います。しかし、EloquentはPHPの世界の唯一のORMではありません。この機会に普通のModelとは一味違ったORM, Doctrineに入門してみませんか?
特にDoctrineMigrationsの便利さは、Laravelユーザーの皆さんに一度体験してみてほしいです!
Laravelで多機能なアプリケーションをモジュラモノリスとして開発・メンテナンスしていこうとする時、Modelの依存は悩ましい点になっていると思います。AモジュールにあるModelがUserを、UserがBモジュールにある別のModelを参照してしまうと、結局疎結合にできず、メンテナンス時に依存を排除できません。
LaravelであってもORMとしてEloquentではなくDoctrineを使うことで、モジュール同士が依存しない、疎結合なモジュールによるモジュラモノリスが実現可能です。
実践的なモジュラモノリスLaravelのサンプルコードとともに、LaravelからDoctrineを使う実装についてご紹介します。
モノリス全盛期〜マイクロサービスブームを経て、近年、両者のいいところ取りができるアーキテクチャとしてモジュラモノリスが話題になることも増えてきました。PHPでも流行のLaravelフレームワークでのやり方やハマりポイントの記事がありますが、基本的に密結合を指向しているLaravelをベースにかなり無理をして実現している事例を見かけます。
私が数年にわたってSymfony+Doctrine ORMをベースにモジュラモノリスでアプリケーションを開発してきた経験から、Laravelベースで開発するよりも数段楽にモジュラモノリスを実現できることを証明したいと思います。
テストを書くとき、テストデータ(テストフィクスチャ)をどのように用意していますか?プロダクションコードを改修するとき、テストフィクスチャにも多数の改修作業が発生してつらくなっていませんか?
私は10年近くテストのある開発をしてきた経験から、テストフィクスチャもオープン(拡張に対して開いている)で、クローズド(修正に対して閉じている)にするのが良いのではないかと思うようになりました。
このトークではまず様々なテストフィクスチャの作り方を概観した後、オープン・クローズドなテストフィクスチャを実現するために現時点でベストだと私が思う方法をお伝えします。
このトークでは、10年近く運用されているサービスにおけるPHPフレームワーク(FuelPHP 1.8.2からFuelPHP 1.9-dev)とPHPのバージョンアップ(PHP 7.3からPHP 8.1)の戦略について語ります。
FuelPHPは2023年7月現在、PHPの最新メジャーバージョンに対応したバージョンを公式にリリースしていません。
開発が完全に止まってしまったわけではありませんが、LaravelやSymfonyなど他のフレームワークと比べるとモダンという印象は持てないかもしれません。
FuelPHPを使っている方はもちろん、それ以外のPHPフレームワークを使っている方も対象に、PHPフレームワークとPHPのバージョンアップの知見を共有します。
様々なトレードオフやハードルを乗り越えるために、どのように計画し、アプローチしたかをお話します。
ソフトウェア設計やアーキテクティングって、とっても難しそうですね
─がしかし、普段のコードを書く時にも我々は「設計について」から逃れられない訳です!
「設計が良い悪い」以前にある筈の「どんなものが気持ちいいのか、求められるのか」を説明できていますか?
知識としての「○○原則」や「○○パターン」で片付けない審美眼を持ちましょう
このトークでは、なるべくやわらかく「そもそも設計って何で必要なんだろう」をシェアします
目の前に立ちはだかる削除フラグ......
削除フラグがアンチパターンであることは知っていても、目の前の削除フラグと付き合っていくしか無い...
そう思って諦めていませんか?
削除フラグを既存のアプリケーションに影響をできるだけ閉じて無くすことはできます。
テーブルから状態や属性を別のテーブルに移し、アプリケーションを壊すことなくリファクタリングしていくために必要なことを説明します。
レガシィコードと向き合い、リファクタリングして、目の前のプロダクトを改善している現場のテクニック、余すこと無くお話します!
生涯エンジニアを続けたい。
しかしインターネットを見渡せば凄腕のエンジニアばかり。
このまま、自分は生き残れるのだろうか...
私も今年、38歳を越え、職場ではCTOとして決断を迫られる中、それでも新しい技術を理解し、向き合って行かねばなりません。 もちろん一日は有限ですから勉強する時間も限られます。
そんな中、私がどうやって新しい技術を理解し、未来の技術を予測し、今の技術を選定しているか。
そのために日々をどう過ごしているか。そんな "エンジニアとして生き残るためのhack" を皆さんにお伝えします。
ピカソは言った。「優れた芸術家は模倣し、偉大な芸術家は盗む。」
先人の言葉を例に上げながら、課題を解決するエンジニアになるためのロードマップをお話します。
Webアプリケーションは生き物です。
作って終わりではなく、日々運用を行っていかなければいけません。
しかし、日々成長するWebアプリケーションは突然パフォーマンスが問題になり、サービス障害を生み出します。
そこで今日はシンプルなLAMP環境で動くようなWerbアプリケーションのパフォーマンス・チューニングの勘所についてご紹介します。
基本的な考え方から実際の明日から役立つテクニックまで全部ご紹介します!
PHP 8.1から始まった、mbstringの大規模改修。
それをまとめたところ、大規模改修をしているAlex DowadさんからFYA(For Your Action)をもらうようになり、レビューをしていました。
すなわち、mbstringの変化をリアルタイムで見るようになってしまったのです。
2022年12月から始まったこのゆるい関係は、ときに入ってきたプルリクエストをサポートしたりとたくさんの出来事がありました。てきめん自身もプルリクエストを送りマージされたため、GitHub上でContributorフラグをもらえました。
また、php-src上で誰に何を投げれば良いのか段々とわかってくるようにもなりました。
本トークでは、PHP 8.3のmbstringの変更点・貢献内容はもちろんのこと、php-srcへのコントリビュートに挑戦したい方への足がかりになれば幸いです。
多くのWebサイトではメールアドレスをIDとしてユーザーを管理しています。この設計はフレームワークの機能として用意されることもあります。
しかし実際のサービス運用のためには、いくつかの考慮事項があります。
要約するとたった二点ですが、実要件は運用形態や提供したいサービスによって様々です。たとえば、同じユーザーからの複数登録を許容しない、特定のドメインからの登録を禁止するなどです。
一見明確でも、単純に実装できない要素がいくつもあります。メールアドレスや関連仕様、DB製品とCollation、メール配信サービスプロバイダ、ユーザー認証プロバイダなども影響します。
メールバリデーションライブラリの実装を通じて、アカウント管理に必要な観点をみつめなおしましょう。
みなさんは何かしらの VM (Virtual Machine)を作ったことがあるでしょうか。私自身は過去に PHP で JVM (Java Virtual Machine) を作ったことがあります。
現職は Ruby on Rails がメインの企業です。Rails どころか Ruby 初心者である私が Ruby の気持ちを理解するにはひと工夫必要だと考えました。
そこで,過去に PHP で JVM を作ったことがある経験を活かし,RubyVM を自作して Ruby の気持ちを理解し学習速度を加速させようという考えに至りました。
本トークでは PHP でどのように VM というものを作るのか,そして RubyVM はどのように作っていくのかを,初心者でも「ちょっとわかったかも」と思えてもらうことをゴールとして解説します。