はじめに
ラクスのメールディーラーを開発している、neroblubrosです。
2021年5月29日（土）にPHPカンファレンス沖縄が開催されました。
当初はオンラインとオフライン（会場での参加）を予定されていましたが、沖縄が緊急事態宣言下となり急遽オンラインのみの開催となりました。
弊社から6名のエンジニアが参加いたしましたので、参加したセッションのレポートをご紹介いたします！
では、レポートスタート！
なお、レポートはRoomAからBの順で開始時間順に記載しています。
- はじめに
- Room A
- プログラミング言語に依存しない、質の高いコードを書く技術
- PHPでCSVのインポート/エクスポートに立ち向かう
- 3年規模のモバイル開発(Flutter)のバックエンドにLaravelを採用したお話
- PHPでthrowしない例外ハンドリング
- リーダブルコミットのすゝめ
- 今日からできる安心型付け入門
- Room B
- 技術的負債を返し続ける取り組み ~ あなたのPHPのバージョンいくつですか？~
- 理解しておくべき PHP のバリデーション
- たまには PHP で、パーサ(構文解析器)を書いていこう
- 実践！PHPWebアプリケーション パフォーマンスチューニング
- まとめ
Room A
プログラミング言語に依存しない、質の高いコードを書く技術
report by id:Jazuma
CBcloud株式会社所属のあらかき ゆうじ さんの(@arakaji)セッションです。
「コードの品質」と「プロダクトの開発速度」はトレードオフではないという話から始まりました。
質の高いコードを書くことでバグを減らしたり、影響範囲の調査がスムーズに進むため、開発速度も上がるとのことです。
セッションでは、保守性の高いコードを書くための具体的な手法が紹介されました。
1. モジュール性
2. 再利用性
〇 モジュール性
依存関係や変更の影響範囲が適切にコントロールされていること。
「モジュールを変更する理由はたった1つであるべきである」という単一責任の原則が強調されていました。
例えば、従業員情報を保持するクラスに「給与計算」「労務管理」「個人情報」の3つのメソッドが配置されているのは望ましくありません。
1つのメソッドに対する変更が他のメソッドに影響を与える可能性があるためです。
似たようなメソッドでも使われ方が異なるものは別々のモジュールに切り出すべきという部分が参考になりました。
〇 再利用性
あるモジュールが1つ以上のクラスやシステムに利用できること。
再利用しやすいコードを書くことで同じ変更を何回もすることがなくなるため、開発速度を上げることができます。
他のメンバーだけでなく、未来の自分も恩恵を受けられるというのが印象的でした。
再利用しやすいコードを書くには「小さいものは美しい」というUNIXの設計思想が役に立ちます。
多くの機能を盛り込んだ大きなモジュールではなく、1つの機能に特化した小さなモジュールを組み合わせることが重要だと思いました。
PHPでCSVのインポート/エクスポートに立ち向かう
report by id:Y-Kanoh
Webサービス開発において、CSVのインポートやエクスポートは、避けては通れない機能だと思いますが、文字化けやエスケープなど、考慮点が多いのが現実です。
しかし、よく使うということは、当然ライブラリも用意されております。
本発表では、league/csvというライブラリを用いることで、fgetcsvなどを使った独自実装なしでも、イテレータによる行データの取得や、CSVでのダウンロード機能などの実装方法を紹介しておりました。
また、発表者自信が作成されたCSVインポート/エクスポートライブラリも紹介されていました。
CSVの操作は確かに自分で実装しようとすると、考えることが多く、悩みどころです。
私個人としては、UTF-8で記述されたCSVファイルでも、BOM付きにすることで、Excelでも文字化けせず開くことができることが、初耳だったため驚きでした。
3年規模のモバイル開発(Flutter)のバックエンドにLaravelを採用したお話
report by id:richardwagner
モバイル開発（Flutter）のバックエンドにLaravelを採用したというお話です。
モバイルのバックエンドもSPAのAPI開発と一緒でしょう、ということであえてLaravelを採用されたそうですが、大きく支障もなく導入できたという心強い内容です。
個人的に気になったのは以下のポイントでした。
- リアルタイム更新には弱い。特にPush通知はPHPでは事例が少なくやりにくい。結局Firebaseと併用。
- Laravel技術者がとても多く、開発リソース確保の面で悩まなくていいのは大きなメリット。
- WebでもFlutter×Laravelの事例は圧倒的に少なかった。
事例の少ない中でも果敢に挑戦し、貴重な経験値を積まれた向江さんのチャレンジ精神をぜひ見習いたいと思いました。
PHPでthrowしない例外ハンドリング
report by id:Y-Kanoh speakerdeck.com
"例外"とは何かと考えると、一言では説明しづらいものです。
こちらの発表では、概念としての"例外"を「どのように処理すべきか織り込まれていないイベント」、プログラミング言語としての”例外”を「どのように処理すべきか織り込まれていない状態になったことを外部に伝える手段」として定義し、PHPの基本的な例外処理である throw try-catch-finally が抱える難しさについて説明されておりました。
また、他の言語での例外処理を参考に、PHPで throw を使わない例外処理についても解説されていました。
今までふんわりと行っていた例外処理について、さまざまな視点から考えさせられる内容でした。
リーダブルコミットのすゝめ
report by id:Y-Kanoh speakerdeck.com
コミットメッセージは、他人、つまり同僚やコントリビュータ、未来の自分が読んで、内容を理解できるものである必要があります。
これは、コードを読むだけではわからない背景や、意図をコードの読み手に伝えることによって、コードレビューの負担を減らしたり、忘れていたコードの意図を思い出すために必要です。
そのためには、コメントに決められたプレフィックスをつけることや、内容はできるだけ「Why（コードを変更した理由）」を書くことを意識する必要があり、さらに読み手が読みやすいよう、フォーマットの工夫や、チケットやIssueへのリンクを設置することも効果があります。
アンチパターンとして用意されていたコミットコメントが紹介されるたびに、耳が痛くなる内容でした。
気を抜くとどうもおざなりになるコミットコメントを、書き手と読み手のコミュニケーションのために、真面目に考えるべきだなと改めて考えさせられた発表でした。
今日からできる安心型付け入門
report by id:radiocat
プログラミング言語において避けて通れない「型」という概念ですが、その制約が比較的緩いところから生まれたPHPでは進化の過程でその立ち位置を変化せざるを得ないことが多々あり、我々はその変化にある意味振り回されてきました。
そんなPHPプログラマーが受け入れるべき「型」という概念を、基本的な考え方から、なぜそのように扱うべきなのかという背景も含めて丁寧に解説し、型を正しく扱う方法を学ぶことができる内容でした。
弊社が開催している PHP TechCafe にもたびたび参加して頂き、いつもわかりやすい解説をして頂いてるうさみさんならではのPHPエンジニアにとってためになる講義でした。
Room B
技術的負債を返し続ける取り組み ~ あなたのPHPのバージョンいくつですか？~
report by id:neroblubros
開発をしているとOSやミドルウェアなどのバージョンアップを行わなければなりません。
また、非推奨のAPIを使っていたり、リファクタリングが必要なコードなど、それらをひっくるめて技術的負債と呼ばれています。
一方で技術的負債は費用対効果が見えにくいことが多く、その結果、プロダクト開発が優先され技術的負債が負債のまま取り残されるケースもあります。
当セッションではプロダクト開発をしながらどうやって技術的負債を返済していくか？を紹介されました。
私が「なるほどな」と思ったのは「開発とは別軸の優先順」でやるということで、プロダクト開発とは切り離して技術的負債の解消に取り組めば、放ったらかしにならないのか！と納得しました。
セッションの時間が10分と短かったのですが、弊社のようなクラウドベンダーに有意義なセッションだったと思います。
理解しておくべき PHP のバリデーション
report by Jazuma
Torana, Inc - 株式会社トラーナ | 所属 めもりーさん(@m3m0r7) によるセッションです。
PHPにおけるユーザ入力値のバリデーション実装方法について豊富な具体例を交えながら説明されていました。
登壇者によるセッション内容のまとめは以下の通りです。
- バリデーションをちゃんとやろうとするとしんどい
- プロダクトの要件に合わせて妥協するのも1つの手
- バリデーションのロジックを自前で実装すると保守コストがかかる
続いてバリデーションの悪い例と良い例が紹介されました。
一部を抜粋します。
数値のバリデーション
○ 悪い例
- is_numeric($number) : 1e10のような入力値が通ってしまう
- is_int($number) : 数値型だと通らない。 intに変換するとバリデーションの意味がない。
- ctype_digit($number) : 入力値が負の数だと通らない。 正の数しか受け付けないという要件ならok
○ 良い例
- filter_var($number , FILTER_VALIDATE_INT) !== false : PHPの組み込み関数で実装するのが手っ取り早くて楽
メールアドレスのバリデーション
○ 悪い例
- 正規表現でバリデーション： 漏れが発生しやすい＋ 可読性が低くなる
○ 良い例
- filter_var($email , FILTER_VALIDATE_EMAIL):
下手に自前で実装するよりも組み込みのfilter_var関数を使うほうが良い場合が多いようです。
PHPに限らずバリデーションについては一般的に以下のようなことが言えるように思いました。
- 独自でバリデーションロジックを実装すると考慮漏れが起こりやすい
- したがって、言語の標準関数を利用すると良い場合が多い
- 正規表現は可読性が落ちるのでできれば避けたい
たまには PHP で、パーサ(構文解析器)を書いていこう
report by takaram
PHPのパーサライブラリ "Parsica" を使った構文解析のお話でした。
私は構文解析というと、PHP本体（Zendエンジン）がやっているように、C言語でyacc/lexなどを使ってやるもので「難しそう……」というイメージでした。
このセッションではURIのパースを題材に、スキーム・ホスト・パスなどURLの各パーツの構造をPHPコードに落とし込み、最後に組み合わせてURIパーサを完成させる過程が紹介されました。
「小さいパーツを作って組み合わせる」やり方は非常にわかりやすかったですし、Twitterでの反応にあったようにUNIX哲学にも通ずるものがありそうです。
> 小さな部品を作って合成できる
— おかしょい (@okashoi) 2021年5月29日
UNIX 哲学じゃん #phpcon_okinawa #track_b
個人的には、正規表現では難しいメールアドレスのバリデーションもこれを使えばできるのでは？と期待しています。
実践！PHPWebアプリケーション パフォーマンスチューニング
report by takaram
PHP製Webアプリケーションのパフォーマンスチューニングに関する発表です。
WebサービスチューニングのコンテストであるISUCONの過去問を題材に、実際のチューニングの例を見ることができました。
「推測するな、計測せよ」
これが今回の発表のキーワードでした。
いかにスピードアップするか？の手法も大切ですが、それ以前にどこがボトルネックか？を正確に把握しなければパフォーマンス改善はできません。
勘に頼るのではなく、計測→原因特定→改善のサイクルを愚直に実行せよ、というのが発表の趣旨でした。
私自身、パフォーマンスチューニングには「経験がないから」と苦手意識がありましたが、大事なのは経験や勘ではなく愚直な計測だとわかったので、今後は苦手意識もなくしていけそうです！
あとPHP8+JITすごい（小並感）
まとめ
前述の通り、沖縄に緊急事態宣言が発出され開催自体どうなるのかな？と思っていましたが、オンラインのみではありますが開催されてよかったです。
逆に全国各地にいてもオンラインで参加できるので、他社の事例など有用なセッションを気軽に見られるようになり、有意義なカンファレンスだったと思います。
まだまだ、セッションの動画は公開されていますので、折を見て気になるセッションを見てみようと思います。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gleイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com
