トーク

6年続くWebサービスをリプレイスすることになりました。
あなたならまず最初に何から手を付けますか？

このトークでは、弊社（コネヒト）が運営するママ向けNo.1アプリである「ママリ」のシステムの一部（CakePHP2.x / PHP7）をリプレイスしている状況を共有したいと思います。
長年に渡って機能改修が繰り返され、複雑なドメインを有するサービスは単純にフレームワークを新しくしたり、あるいはLaravelなど別のフレームワークに載せ替えるだけでは解決できない問題がたくさんあります。

様々な工夫を凝らし、今回の基本戦略である「無駄な物をなるべく作らない」という方針でどうやってリプレイスを進めているのか、具体的なプラクティスを交えながらご紹介します。

PHPで画像に縦書きテキストを描画する話です。
横書きテキストしか描画できないImageMagickと、ICU (Intl) を使って実現します。
発表では以下の内容を踏まえて縦書きテキストを画像に描画する方法とその要素技術についてお話しします。

• 縦書きテキストとは何か
• テキストを構成する文字について
• 文字を描画するためのフォントファイルについて
• フォントファイルを扱う時に便利なttxというツールについて
• PHPから使えるImageMagickについて
• PHPから使えるICUについて
• 文字列を折り返すということについて

2021年のPHPはPHPStanやPhan、Psalmを用いる事で型検査や不要なコードの検出が可能です。
新規のプロジェクトでは、初期から静的解析ライブラリを導入することにより実行時エラーをデプロイ前に検出することができますが、古くからあるプロジェクトでは、導入しても十分に静的解析の力を発揮することができない場合があります。
古くからあるプロジェクトに静的解析ライブラリを導入するために、何が静的解析の障害となっているか調査しました。
計画的にレガシーコードのリファクタリングを行なうために行なったコードの解析手法についてお話しします。

AWS,GCPなど様々なクラウドリソースのコード管理を実現するTerraform。
小規模なインフラ構成であれば単一レポジトリにディレクトリを分けずに配置して、シュッとお手軽に利用できます。
しかし、大規模な構成になってくると、途端に管理が面倒になり、ベストプラクティスも存在しない世界になります。。
このトークでは、Terraformのレポジトリ、ディレクトリ構成について、これまでの苦闘した軌跡と、現状のベストだと思う構成、将来的にどうあると良いと考えているか？について話します！
トーク後にはぜひみなさんとディスカッションしていきたいです〜

最近の PHP コードは意外と型の恩恵が得られます。
PHP 7.0 でのスカラ型宣言、7.1 での nullable、7.4 でのプロパティ型宣言、 8.0 での Union や明示的 mixed の導入といった言語自体の機能追加もあるのですが、psalm や phpstan といった静的解析ツールを利用することで、静的型検査や mixed の排除、Type Erasure な Generics の利用といったことさえできます。
このトークではそんな最近の PHP の型事情、ツールについてのお話や、実際に静的解析ツールを最高レベルで利用し型をガチガチにしながら PHP コードを書く際の注意点についてお話します。

PHPでは配列の初期化処理がopcode列にコンパイルされて実行されるため、巨大配列の初期化は実行時にコストがかかっていました。ところが、PHP 7からは定数だけで構成された配列リテラル（＝定数配列）をコンパイル時に生成して利用するように変わっています。さらに定数配列はOPcacheのキャッシュ対象になっているため、キャッシュヒットすれば巨大な定数配列を生成コストなしで使えるようになっています。本トークでは技術的背景を簡単に説明した上で、定数配列とKVS（APCu・memcached・Redis）で同じ機能を実現した場合の性能比較を行います。

いわゆる「大規模」と言われるウェブサービスで、SEOを考えるときに直面するのが、「クロールバジェット」と呼ばれている、クロール割り当ての最適化です。
婚活パーティーのポータルサイトであるオミカレでは、最大で4万件以上の婚活パーティーの情報と、それを検索するための都道府県・市区町村・ジャンルといった多種多様なリストが存在し、「ページ」数は膨大なものとなっています。
その膨大な中から「Googlebotに見てほしいページ」にどうやって効率よく誘導するか？はとても大きな課題です。
そこで、2019年6月に行ったオミカレのフルリニューアル以降、直面したクロールバジェットにおける問題や対処法について紹介します。

主な内容

• 立ちはだかるリニューアル前のURL
• 想定通りにならないcanonical
• 第一回リダイレクト祭り
• 居座るはるか昔の日付
• 一筋縄では行かないrobots.txt
• 検索とパラメーターとインデックスとランディング
• 終わらない内部リンクの検証
• 第二回リダイレクト祭り
• これまでの教訓

「プロダクト開発が、メンバーの技術力を高めるのか」「メンバーの技術力向上が、プロダクトの品質や可能性を高めるのか」
皆さんは、この「鶏が先かと卵が先か」に似た構造を持つ問題についてどのような考えをお持ちでしょうか？

本セッションは、自分自身の取り組んでいることを紹介した上で、
オーディエンスの皆さんからの視点や経験を織り交ぜたフィードバックと議論を集め、『共有知』を生み出す試みとしたいと考えています。
(折角のオンライン＆録画発表なので！)

この課題を選んだ背景

プロダクト開発や(Web)サービスの提供を行う会社において、
Webエンジニアに求められる主要な成果は「プロダクトを良くする」ことだと思います。
プロダクトをよく出来るエンジニアとは、どういう存在でしょうか？
実は、「プロダクトをよく出来るエンジニア」になるには「プロダクトを開発する以上の技量」が要求されるのではないでしょうか。

ここには大きな矛盾があると考えています。
「プロダクトを良くし続けるには、プロダクトに必要なレベルの技量では足りない」という矛盾です。
これについて、自分自身が、所属先の企業でのロールが変化したのをきっかけに取り組むようになりました。
組織の姿が「プロダクトを作れる」を超えた「プロダクトの未来を作れる」ようになるにはどうすればよいか・・？と現在進行系で考えています。

紹介するお話

例えば、以下のような取り組みが「自分なりに考えたこと」でした。

• 「技術力」を定義する
• プロダクトと技術力の関係
• 自分自身が「技術的な成長」を感じた瞬間を構造化して捉える
• その「良いフィードバックの獲得の仕方」を組織的に再現できないか？

こうした話を「議論のネタ」として提供したいと考えています。

私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。
私はこれを「Documentation as Code」と呼んでいます。そして、そのような概念はすでに世の中にあり、時として「Documentation as Code」と呼ばれているようです。
例えばPHPDocなどはソースコード自体の構造とアノテーションをトレースしてドキュメントの自動生成を実現しています。
OpenAPIのように構造化されたデータとして情報を記述することでドキュメントと同時にAPIクライアントやの自動生成が実現できている例もあります。
テストケースに振る舞いを自然言語で併記しながらテストコードを書くことで結果としてテスト仕様や要求仕様のドキュメントで実現するようなアプローチもあります。
私もシステムやコードからドキュメントを生成するようなツールを少なからず作ってきました。
そういった経験から、本発表では、上記のような「Documentation as Code」を実現するツールを独自にモデル化してそれぞれの特性について考えていきます。
そして本発表を通じて皆さんが「Documentation as Code」に興味を持ってもらえればと嬉しいです。

エンジニア向けイベントのスポンサー担当をここ数年やっています。
会社としてはもともとそんなに積極的にスポンサー活動をしていたわけではないので、どういったことをきっかけにするようになったかの背景を始め
・スポンサーするにあたって予算とかどうしている？
・効果測定は？
・実務面では何している？
について話します。
このトークをきっかけに、より多くの会社様がエンジニア向けイベントのスポンサーになってもらえればと思います。
もっともそれ以前に、スポンサー担当していると、自社のロゴがイベントサイトに掲載されたり、会場でロゴがあったりするだけでイベント参加が一段と楽しくなるので、そういう楽しさを是非共有したいです。

比較的モダンなフレームワークでは、例外処理や例外発生時の検知・ロギングが仕組まれていますが、PHPでは検知をすり抜けてアプリケーションを終了させる手段が多数存在します。本セッションではPHPのプログラム実行の仕組みから、どのようにすれば検知の網の目をすり抜けることが出来るのかを解説します。この知識を得ることによって、逆にどのようにアプリケーションを作成すれば、比較的安全を担保できるのかが理解できるようになります。

このトークでお話すること

• PHPの例外検知機構と検知不能が発生する仕組み
• 最後の悪あがき「register_shutdown_function」の仕組み
• 検知不能状態を検知する方法の提案

バージョン 8 にしてとうとう僕らの PHP にも JIT がやってきました！
が、PHP 8 の JIT は生まれたてで、同じ 8 でも JavaScript の V8 にはまだまだ速度的な面で追いつかない部分があります。
PHP と JavaScript のそれぞれについて、おおむね同等の処理を行うマイクロベンチマークのコードを用い、プロファイルをとりながらああだこうだ言いつつ速さの特性差や PHP の現状の限界、得意な点や不得意な点を探っていきます。

■ 想定する聴講者
典型的な Web アプリケーションは主に I/O バウンドとかそういう現実の話は脇に置いておいて、PHP スクリプトの性能や測定方法が気になる人
今後の PHP の性能の伸びしろに思いを馳せたい人
しょうもないマイクロベンチマークが好きな人

■ お話しないこと
明日から業務に使える役立つ知識

新規サービス開発において、PHPウェブアプリケーションを実際に世界に向けて動作させるためのインフラが必要になります。では、一体どのようにしてインフラを選定したら良いのでしょうか？プログラミングの世界ではDRYやYAGNI等の格言や、アーキテクチャー選定の考え方が浸透していきていますが、インフラにおいては、基準が曖昧です。本セッションでは、ウェブアプリケーション初期構築時のインフラについて実例を紹介しつつ、妥当なインフラを選択するための基準を紹介します。

このトークでお話すること

• 選択可能なインフラ環境
• 選定時の基準
• 各環境の利点と欠点

ステートレスなHTTPをステートフルに変えてくれる仕組みがセッションです。ユーザのログイン、リダイレクト後のエラーメッセージの表示、CSRF対策等、現代のウェブアプリケーションで多用されているセッションですが、セッションがどのように動いているかと聞かれた時に正しく答えられますか？
初心者に近いPHPerがセッションを多用すると、中堅クラスのエンジニアから「セッションは危ないから多用しないように」とアドバイスされることも多いと思いますが、それは何故でしょうか？

本トークでは、ウェブアプリケーションにおけるセッションについて、その正体を分かりやすく解説します。また、セッションの正体を知ることで、ウェブアプリケーションのアーキテクチャーに対してセッションが及ぼす影響についても解説します。セッションにまつわるアレコレを解説することで、初心者とベテランエンジニアの間に存在する知識と経験の差を少しでも埋めることが狙いです。

このトークでお話すること

• セッションの仕組み
• ウェブアプリケーションフレームワークにおいて利用されているセッションの例
• セッションが本番アプリのアーキテクチャに与える影響

bugs.php.net は PHP の公式 issue トラッカーで、処理系本体と公式バンドル拡張、PECL 拡張をあわせて現在 2000 以上の未解決のバグが登録されています。

古いものでは PHP4 時代のチケットで残っているものもあり、現在サポートされている処理系バージョンにおいてすでに解決済のものや、そもそもバグではないもの、当初は明らかにバグだったとしても 10 年以上その挙動が続いたことで、もはや仕様としてしまった方がよいのではないかと疑われるものなど、色々なチケットがあります。

そんな bugs.php.net の古くからある塩漬けチケットについて、現在サポートされている PHP 7.4 以降でも再現するか、レポート内容が妥当かなどを検証しつつ、修正可能なものについては PR を投げ、修正不可能であったり修正の必要がないものについてはコメントを追加して現在の状況を付記する、という清掃活動に取り組んでみました。

bugs.php.net 自体やチケットの調べ方について紹介しつつ、見つけて面白かったチケット、実際に対応したチケットについてお話します。

PHP 8で導入されたattributes。
今まで（やむをえず）PHPDocを用いて実装されてきた様々な書き方が、だんだん置き換わっていこうとしています。
今回は、DIの代表的なライブラリであるPHP-DIが新しいバージョン（7、2021年1月19日時点では未リリース）でどう変わろうとしているか、また、Symfonyなどの変化もあわせて紹介しつつ、PHPにおけるDIの行方について話したいと思います。

PHP 7.4 で追加された FFI を通じて、 Linux の FUSE を利用することができます。
つまり、今や我々は PHP でファイルシステムを作ることができるのです。
たとえば WordPress ファイルシステムを作ってマウントすることで、grep や sed を通じて DB 内の記事データを編集するような誰得な操作も可能となります。
このセッションではそんな FFI による大道芸、PHP によるシステムプログラミングの実例とそこで使われている技術について簡単にお話します。

Everything Will Be Serverless.
そんな未来は来ないかもしれません。
しかし、私はそんな未来を信じてお話します。

話者は昨年AWS上でFull Serverless SPAの構築を行いました。

今までサーバーを意識したPHPのWebアプリケーションを作成する事が多かったの話者が、
サーバーやRDBMSを使わないFull Serverless なWebアプリケーション構築を通して学んだ知見を共有します。

ServerlessなGo APIとReactのSPA構成を構築して実感した所感もお話できればと思います。

■利用言語、フレームワーク

• Go
• React x TypeScript

■利用AWS リソース

• AWS Lambda
• Amazon DynamoDB
• Amazon S3
• Amazon CloudFront
• Amazon Cognito
• AWS Amplify
• Amazon Athena、Amazon S3 Select
• Step Functions、AWS Batch

■想定する聴講者

• Serverlessに興味がある方
• AWSが好きな方
• 理論はわかるけど実際に構築したことが無い方

■お話する内容

• 実際の構成について
• ServerlessなSPAの開発手法について
• APIとフロントエンドの結合部について
• 開発からリリースまでで実感した所感

みなさんサーバーレスってますか？PHPerでもサーバーレスってますか？
どうやら世の中サーバーレスだったりマイクロサービスだったりがモダンなようです
AWSは使っていても、構成は結局LAMPどまり…というぼくが、次の新規案件にサーバーレスを採用しようと決めました
一足遅くなりましたが、このビッグウェーブに乗ろうとしたぼくの過程をお話ししたいです

ためしに、このトーク用に #サーバーレス で動くモノを作ってみたいと思います

PHP界隈でもドメイン駆動設計の話題が盛んな昨今ですが、正しい設計のためには前工程としての要件分析が不可欠です。詳細な設計に入る前にプロダクトオーナーが読み解ける形式の文書で合意を取っておけば、最小のコストで「本当に必要なもの」を作るための足場となります。また、ドメインエキスパートを設計の深いところまで連れて行くための道標も手に入るでしょう。

このセッションでは、システムとユーザーの相互作用をユースケースシナリオとして表現し、そこからオブジェクト指向らしいクラス設計を導く手順を紹介します。設計スコープと目的レベルについて理解し、簡単なフォーマットさえ覚えれば、誰でも明日からユースケースシナリオを活用できるようになります。