セミコロン、書いてますか？

PHPの構文要素には式と文の厳密な区別があり、一般的なプログラミングのベストプラクティスでは、適度な単位で文を区切ることでリーダブルなコードになるとされています。しかしながら式指向の言語機能や関数を利用することでコードを圧倒的に短縮することもできます。この記事においてはセミコロンの数を最小にしながら偏執的なPHPプログラミングを行う非実用的コーディングテクニックを紹介します。

ちょうぜつ Advent Calendar 2020 からの抜粋で、知っておきたいアンチパターンを紹介します。
https://qiita.com/advent-calendar/2020/memory-chan

みなさん N+1 問題ってご存知ですか？DB への接続をループ分で N 回実行し、+1 はカウントで全件数を取ってきたりすることを総称して N+1 問題というかと思います。他にもループ分で N 回実行しているコードだけのものも総称して N+1 問題と言ったりしますね。言葉の真意は神のみぞ知るですが、概ねこういった理解の方が多いのではないでしょうか。もちろん N+1 は DB に限らず外部リソースへの接続も同様と理解すべきです。外部リソースといえばキャッシュ用の Redis もそうですし、全文検索エンジンの Elasticsearch も同様です。1 回の接続であれば目を瞑ることもできますが、ウェブアプリケーションとして稼働している場合、そういうわけにもいきません。そして、N+1 問題はパフォーマンスチューニングにおいて重要なファクターの一つにあげられることも多いかと思いますが、具体的な改善方法は中々調べても出てきません。そこで、本トークでは N+1 問題をそもそも生み出さない方法はどうするのか、既存のアプリケーションから N+1 問題を改善するためにはどうしたらいいのか、といった今後あなたが開発をしていく上での一つの引き出しになれるようなトークを私の今までの経験を交えてできればと思います。

LTしたことある人、挙手。
カンファレンスで登壇したことある人、挙手。
本書いたことある人、挙手。
何かアウトプットしていますか？Twiterやブログだって十分です。

登壇や執筆なんて、つよつよエンジニアだけができるものだと思ってませんか？違いますよ？もっとカジュアルに登壇・執筆・アウトプットしてみましょう。

トークに自信がない？ネタがない？自分なんて初心者だから？そんな幻想・呪縛はポイです。あなたの「今」を切り取ったアウトプットをしてみましょう。必ず誰かが聞いてくれます。必ず誰かの役に立ちます。そして自分も得るものがあります。必ず次につながります。

アウトプットの始め方、育て方、広げ方、トークネタの作り方、そのあとの広がり、やってうれしかったこと、などなど。

やってみようかなと思った時がはじめ時。アウトプットをはじめることで開ける優しい世界の一端を紹介し、あなたをアウトプットの世界にお誘いします。

PHPerの皆さんは、日々Webアプリケーションを開発している中で、フレームワークのコードと自分たちのコードを区別できていますか？
自分たちのアプリケーションにとって重要な、業務知識をモデリングして書いたコードは、「いまのフレームワーク」と切り離して動かすことができるでしょうか？

フレームワークのバージョンアップ、あるいはフレームワークの開発終了によって自分たちのアプリケーションの命運が左右されることがないように、フレームワークへの依存を取り除き、大事なコードの可搬性を高めましょう。
ごく一般的な小さなWebアプリケーションを題材に大事なコードを守りつつLaravelからSymfonyにフレームワーク変更する様子を実演しながら、考え方とテクニックについてご紹介します。

Advent Calendar（アドベントカレンダー）、以降アドカレと呼称します。
エンジニア界隈の人なら聞いたことがある人が多いでしょう。
エンジニア界隈でいうと12/1~25に記事を投稿していくイベントです。

僕が所属している組織では6年連続でアドカレを実施しています。
私は実施1年目からの発起人です。
はじめは人が集まらず1人でいくつも記事を書いてなんとか25個埋めていました。
運営として代表としてこれではいけないと思い
・地道な声掛け
・せっかく参加して投稿してもらった記事はしっかり読んで感想をFB
などコツコツ続けた結果6年も続けることができています。

・どんなキッカケで開始されたのか
・アドカレを行なうメリット、デメリット
・6年やって見えてきたもの
・これからやってみようと思う人と団体にアドバイス

このあたりを中心にお話できればと思います。
みんなアドカレやろうぜ！

「ママリ」を運営するコネヒトは2020年12月にConnehito Tech Visionとして「Beyond a Tech Company」というビジョンを公開しました。本セッションでは、なぜテックビジョンをつくったのか？そもそも、テックビジョンとは何か？といった話から、技術のコモディティ化が進み、アフターデジタルな世界の実装が進む中で、今後開発組織はどうあるべきか？どういった技術戦略が求められてくるのか？といったお話を出来ればと思います。本セッションとこのテックビジョンの紹介を通じて、一つの開発組織の在り方を提示したいと考えています。

自分はこれまで、いくつかのバージョンアップを実行してきました。

• PHP 7.2 -> 7.4 、7.3 -> 7.4
• Laravel 5.6 -> 5.7 -> 5.8
• PHPUnit 5 -> 6 (-> 7 -> 8 -> 9)

Docker の利用により以前よりは格段に難易度は下がっているように思うものの、
躓いたポイントや乗り越えた事例をいくつかお話しできればと思います。

「エラーと向き合う」ことは、プログラムの品質を極める上で最重要な要素の一つです。
では、PHPが持つ「エラー」とは、いったい何を意味しているのでしょうか？
面白いのは「時代の流れに応じて変わってきている」点であり、またそれがphperを悩ませるのも点でもあります。
「エラーとは何なのか」、PHP8が登場した今の時代に改めておさらいしてみませんか？

PHPにはたくさんの「異常」を知らせる仕組みがあります。
まず初めに「エラーレベル」があり、PHP5で「例外」が導入されました。次にPHP7で当初"EngineException"と称された「Error」が登場します。
そしてPHP8では、「Error」の適用範囲が増えたり、あるいは(時には処理実行の中断を伴う)エラーレベルの引き上げが実施されました。

最も顕著なのは、組み込み関数でも引数が宣言された型に合致しない場合にTypeErrorを発生させるようになった点でしょうか。
もしくは、未定義変数を利用した場合のエラーレベルがNoticeからWarningに引き上げられた点だ、と言う人もいるかも知れません。
どちらも昨今のPHPが”より真面目に”プログラミングのエラーに向き合うようになりつつある態度を感じます。

本セッションでは、PHP7時代を振り返って「Throwable/Error/Exception」を整理するとともに、エラー関連の挙動に注目しながらPHP8の「堅牢さ」についても考えてみたいと思います。

何らかの理由によって「既存のクラスやAPIの使い方が変更された、それに対応しないといけない！」という場面が、
しばしば開発の現場には発生します。
その時に、なるべく「人間の目と手で作業する」という負担は避けたい・・面倒くさいな・・と思うのが人の心情ではないでしょうか。

https://github.com/rectorphp/rector は、既存のPHPコードのリファクタリングやアップグレードを自動実行するツールです。
こいつを上手く使えれば、あの退屈で機械的な作業を真の意味で「機械の作業」にする夢が叶うかも知れません！！

本セッションでは、Rectorについて紹介し、具体的に活用するための方法を話したいと思います。

おしながき

• Rectorってなに？
• どういう仕組で動いてるの？
• 具体的にどうやって使われてるの？ 〜CakePHP4の アップグレードコマンドを例に〜
• 独自ルールを作ってみる

普段の開発において、OSSのライブラリやフレームワークの利用は欠かせません。
そこで「これはどう動くんだろう」「何でこんな動きをするんだ」と思った時にできること・・・公式のドキュメントを読んで見る、インターネットに公開されているブログ等の情報を探してみる。
そして「ソースコードを読んで見る」、「マージまでの経緯を読んで見る」ことです！
ソースコードを読むためには、多少ボリュームのあるソフトウェアからでも「目的の場所を手早く見つけてみる」のが重要です。
また、OSSならではの利点として、コードだけでなく「そこに至るまでにどんな議論があったか」という情報にもアクセスすることができます。ここでもまた、多少のコツを掴んでおくと便利です。

今まで「フレームワークのコードを読んでみるのは苦手だ」「ググって欲しい情報に近い解説やQ&Aが出てこなかったら諦めちゃう」という日々を過ごしていたあなた！
私の周りにも、「ライブラリのコードを読むのは怖い」「面倒くさそう、億劫だ」という人がチラホラいるものと感じます。
もし「ドキュメント探すよりコード読んだ方が早いわ」という選択肢を手に入れられたら、きっと楽しいことになりますよ・・！

明日からは「もっとライブラリと仲良くなれるぞ♡」な日々を歩んでいきませんか？
本セッションが、そのための勇気をもたらす最初の一歩となれればと思います！

普段みなさんは PHP を動作させるミドルウェアは何を使用していますか。よく一般的に使われるのは Apache の mod_php や PHP に備わっている php-fpm をベースとし nginx からリバースプロキシさせる方法だと思います。
私の所属している株式会社トラーナでは物流をベースとしたシステムが必要になり、どうしても一つあたりのレスポンスが大きいデータを取り扱う必要があります。元々弊社では php-fpm を使用していましたが、パフォーマンスが著しく遅く、そこで swoole と laravel-swoole を導入し、8倍もの高速化を行いました。
そこで、本セッションでは導入する際にハマったポイントや、導入する点でのメリット及びデメリット、そしてどのように導入していくか、最後にどのようにプロダクション環境へと昇華させるかというトークをさせていただければと思います。

弊社のシステムはバックエンドのフレームワークは Laravel を使用、そして OpenAPI と呼ばれる API の設計書を書けば CRUD に対応した API が自動的に実装されるような仕組みを用いて自動生成し、最後にバリデーションを書けば、一つの API が完成します。
もともと弊社の社内システムは SaaS 上にしかなかった、かつバックエンドエンジニアが私一人である中で、どう効率的にゼロベースからプロダクトを組み上げてプロダクトのローンチを早められるかが鍵でした。
CRUD に対応した API 実装、正常系・異常系テストの生成自動化、API のドキュメントの記述、全文検索エンジンへどう自動的に繋ぎこむか、例外処理はどうするか？といった全ての事情を汲み取りながら基盤開発に邁進し、
今では一つあたりの API の実装は 10 分もかからないレベルになりました。本トークでは、この基盤の構築をした経験を元に、考えてきた事、実行してきたこと、判断に迷ったこと、そして Laravel を使った実装についてのお話をできればと思います。

プログラミング覚えたての時、電卓を作るといったことをした方や、今現在プログラミングを学習中で電卓を作っている方もいらっしゃるかと思います。
電卓を作るといえば「1+1」と入力したら単純に「2」が出力されるイメージでしょうか。作っているうちに、「あれ？「((1 + 2) × 3)-((1 + 2) × 3)」みたいな式はどうするんだ？」と疑問に思った方も少なくないと思います。そこで本トークでは3分間という短い時間で、複雑な式を計算できる、もう一段階上の電卓を作る方法についてお話します。

ふと「別の言語も学んでみたいけど、とっつき方がわからない」と思う方も多いのではないでしょうか。
特に近年よく使われる TypeScript などを触ってみたいけど、難しそうと思いなかなか手を出しづらいと思っている方もいらっしゃるかもしれません。
TypeScript をチョットワカルようになるだけでも、業務の分野が広がり、フロントエンドエンジニアの業務がどういったことをやっているのか理解しやすくなります。
ちなみに、私は TypeScript を初めて触ったときに作ったものは、ハムスター監視システムでした。
そこで、PHPer である私がどのように TypeScript を学習し、ハムスター監視システムを作り、そして業務レベルまで扱えるようにしたのか本トークでお話させていただければと思います。

ふと「別の言語も学んでみたいけど、とっつき方がわからない」と思う方も多いのではないでしょうか。
特に近年よく使われる Go などを触ってみたいけど、難しそうと思いなかなか手を出しづらいと思っている方もいらっしゃるかもしれません。
Go をチョットワカルようになるだけでも PHP にはない新鮮さ、楽しさを感じることができます。
ちなみに、私は Go を初めて触ったときに作ったものは、ハムスター監視システムで、もともと PHP で作られていたシステムを学習の意味も含めて Go にリプレイスしました。
主に大きい学習としては非同期に処理ができる WebSocket サーバーの実装をゼロから作り上げた点です。もともと Go は既にいろんな WebSocket のサードパーティモジュールが提供されています。しかし、あえて茨の道を進むことにしました。
そこで PHPer である私が Go を歩むにあたってどのように学習をして、WebSocket サーバーの実装を行っていったかを本トークでお話できればと思います。

待望の PHP8 が出ましたね！
パッケージマネージャーで PHP をインストールすることが多い昨今、ビルドって実際にどうやるんだろう？と疑問に思っている方も多数いらっしゃると思います。
敷居が高そう、難しそう、そう思っている方もいらっしゃると思います。しかし本当は PHP そのもののビルドはそんなに難しくありません。
ということでトークの時間を目一杯使って PHP8 のビルドをオーディエンスの皆様と一緒にライブ形式でやってみたいと思います。
本トークで、ビルドをどうやるのか感覚を掴んでいただき、ぜひ様々なシーンでご活用できるようになっていただければと思います。

TDDは開発者にとって一般的な手法となってきました。そこからさらにAgile開発のようなイテレーション駆動開発となると、イテレーションごとの品質についてワークさせる手法が求められます。

そのひとつにあげられるのがAcceptance Test Driven Development、ATDDです。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。

本トークではTDD自体についても話しますが、そこからさらにアジャイルテストの4象限におけるcheckingに加えtestingについてスコープに入れた大きな単位のフィードバックループの回し方について実例を持って解説いたします。

PHPUnit もバージョン 9 になりました。長年第一線で活躍し私達PHPerにテスト可能な開発環境を提供し続けてくれているPHPUnitは、その分歴史が長く、バージョンごとに これまでの使い方は deprecated になっていきます。

PHPUnit 9 では、さまざまな機能削除や非推奨勧告がありますが、その一つが表題にある MockBuilder::setMethods の deprecated です。

そこで改めてこの変更を機に、次の点を抑えていきます。

• PHPUnitのTestDoubleの語彙整理の根拠 xUTP本とその該当箇所、createStub / createMockの違い
• setMethodsからaddMethods/onlyMethodsになった使い方
• deprecatedになった理由をissueの内容から抑えて背景思想を理解する
• PHPUnit の内部実装ではどのような変更が行われたのか（これはPHPUnit 8でのaddMethods/onlyMethodsの話でもある）

去る9/19〜9/21にiOSDC Japan 2020という技術カンファレスがオンラインで開催され、60本のトークと20本のLTが実施されました。
実施された60本のトークはすべて事前収録され、それを当日に再生する形でカンファレンスを開催しましたが、60本の動画の編集にかかった日数は3日ほどでした。動画編集に詳しい方であればちょっと驚く期間かと思います。

この高速編集を支えたのはPHPでした。

このトークでは私がどの様にPHPでオンラインカンファレンス向け録画システムを構築したのか、そして、同じ様なシステムを作りたい方のためのサービス連携のコツをお話しします。

• Zoom, YouTube Live, Dropbox を連携させた収録システムの作り方
• GD, ffmpeg を使用したオンラインカンファレンス用動画編集システムの作り方
• PHPでサービス連携するためのコツ

このトークを聞いたみなさんが、PHPで高度なシステム連携アプリを作るきっかけになることを期待しています！

参考:
iOSDC Japan 2020
https://iosdc.jp/2020/
iOSDC Japan 2020 トーク動画
https://www.youtube.com/playlist?list=PLod2oSGQp3W4BV6sLUdMwlZD0NHt9mHP7

Track ID: Track3-5-B
Discord Channel: #track3-5-b-online-conference-system