トーク

東京都にある「葛󠄁飾区」と奈良県にある「葛󠄀城市」はどちらも同じ「葛（カツ）」という字が使われていますが、よく見ると文字の形が違っています。
これらの意味としては同じだけど、字形が異なる文字は異体字と呼ばれており、「沢」と「澤」のような分かりやすいものから、「はしご高（髙）」や「立つ崎（﨑）」などの細かい字形が違うものなど様々なものがあります。

日本人には切っても切り離せないこの異体字、Webで扱おうとするとなかなかハードルが高いです。
しかし、実はこの異体字を扱う仕組みは世界中で使われるようになってきており、今ではいくらか制限はありますが、Webでもこれらの漢字が扱えるようになり始めています。
このセッションでは、異体字とはなんなのか、PHPで異体字を扱うためにどんな苦労をした(している)のかを話したいと思います。

話す事
・異体字とは
・異体字がパソコン上でどう扱われているのか
・異体字と外字について
・異体字を読み書きする為の方法
・異体字をPHPで扱う時に困ったこととか

パーサーやインタプリタを作ってみたいと思ったことはありますか？私はあります。
パーサーを作りコードをパースする一連の流れを実装することで、
コンパイラやインタプリタの気持ちを理解できるようになれば、プログラミング言語に対する距離をより縮められると思っています。
「PHPで何を作ろう？」と思ったPHP初心者の私は、この機会にGo言語のインタプリタをPHPで実装することにしました。

本発表では、PHPでGo言語のインタプリタを作成した話をします。
この発表を通して、以下のことを伝えたいと思います。

• インタプリタを作ると何が得られるのか？
• 字句解析、構文解析、評価器とはなにか。それぞれの役割
• 抽象構文木とPHPでの実装方法
• デモ
• 今までGoを書いていたPHP初心者がPHPでインタプリタを書いてみて

対象の言語仕様によってパース処理は異なりますが、インタプリタを実現するまでのステップや流れは同じになるはずです。
この発表を通して聴衆のみなさんが自分の興味がある言語のインタプリタを作り始められるようになるのが、本発表のゴールです。

「エアコン消し忘れた……」
「エアコンをつけたいけどお布団から出たくない……」
「テレビの電源ついてないと録画できないのにうっかり消してきちゃった……」

そのような経験をした方は多いのではないでしょうか？

そんな悩みを解決するために、PHP Webフレームワーク「Laravel」と無線対応のIoT開発ボード「Obniz」を使用した学習型赤外線リモコンを製作して、ブラウザから家電を操作するお話です。

■内容

• Obnizとは？
• 赤外線リモコンの仕組み
• LaravelとObniz間の通信方法
• 時刻起動で自動操作してみる

Web業界に転職して約3年が経ち、任されたのは社内4サービス(そのうちの1つは某ハンドメイドサービス)で利用されるクレカ決済システムの移行プロジェクト。

それは2019年4月末頃に移行本番当日を迎えた、約4ヶ月間にも及ぶ決済システム移行プロジェクトのお話。

発表者は前職で火力発電所の監視システム開発を5年半担当し、そこでは何度も失敗できない現場での業務を経験してきました。
そうした経験を持つ自身が今回の移行成功率を高めるために心がけていたことや実際に実施したこと、またそれでも失敗してしまったことなど、そこで得られた知見を全て皆さんにお話ししたいと思っています。

• 始まりは現行決済サービスの突如終了のアナウンス
• いざ計画した決済システム移行方法はまさかの打ち合わせ数日後に却下
• そして決断されるビッグバンメンテによる4サービス一発切り替えという禁断の計画
• 本番2日前に発覚した重大な設定ミス

移行本番の日、果たしてシステム移行は成功したのか・・・？
乞うご期待ください！

phperkaigiを支えているイベント管理システムfortee。
我々はforteeのソースコードを入手することに成功。そこでforteeに対して脆弱性診断を実施、その結果とは・・・

forteeの開発者 @tomzoh にVAddyによる脆弱性検査の実施を依頼されたため、ローカル環境にforteeを立てて検査してみました。
本発表では、脆弱性検査の種類、検査内容、実際の検査のデモ、検査しやすい箇所としにくい箇所の紹介、
フレームワークを使っていても脆弱性を生みやすい箇所の紹介を行います。
あまり馴染みがない脆弱性検査を少しでも体験して、セキュリティテストは一般的なテストと同じように重要であると理解してもらうのがゴールです。

GitHub 上で PHP の関数やクラスにマウスをあてるとポップアップが表示され、該当の引数の数や、サマリを表示したりマニュアルに飛べたりする Chrome 拡張機能の GitHub PHP Function Jumper の開発の苦労話からどのように作ったのか、 Chrome Web Store への公開、そして今後の展望をノンストップでお届けします。

https://chrome.google.com/webstore/detail/github-php-function-jumpe/pmgmgaejgbjiooiklinoelilmnldlhcf

GitHub 上で PHP の関数やクラスにマウスをあてるとポップアップが表示され、該当の引数の数や、サマリを表示したりマニュアルに飛べたりする Chrome 拡張機能の GitHub PHP Function Jumper の開発の苦労話からどのように作ったのか、 Chrome Web Store への公開、そして今後の展望をノンストップでお届けします。

https://chrome.google.com/webstore/detail/github-php-function-jumpe/pmgmgaejgbjiooiklinoelilmnldlhcf

チームにより良いデバック環境を提供したい、そんな一心で頑張る環境整備。
どのような環境がコスパが良くて、わかりやすい設定ファイルを提供できるのか。
日々みなさんが頭を悩ませていることと思います。
開発環境でのApacheのVirtual Hostは便利ですが、php.ini等の設定が一つにまとまってしまう問題があります。
これをVirtual Hostの数だけContainerに入れてDocker Composeで設定ファイルを割り当てれば解決するのではないかということは考えたことがあるでしょう。
この力技の解法をなるべくスマートに解決してみたいと思います。

話すこと
・Apacheのhttpd.confからDocker Composeへの変換方法
・VirtualHostごとにContainerを建てるとポート番号の管理やURLが面倒になりそう
　・→NginxでReverse Proxyを入れて解決します
　　・Debug用のポートも含め、数個のポート占領で済ませる

PHP 7.4ではFFI機能(https://php.net/ffi)が実装されました。これにより共有ライブラリをPHP上で読み込むことが可能になりました。
今回、Rustで音声ファイルのデコードとエンコード部分を実装して、共有ライブラリとしてPHPで呼び出す際のハマりどころや、PHPとRustの親和性についてお話します。
普段PHPを触っているがRustにも興味がある方、音声ファイルのエンコードに興味のある方、FFIに興味のある方はオススメです！

お伝えしたいこと

「意味を読み取りやすいコード」や「同じ事を同じ書き方で表現させる」のは、チームでの品質保持や生産性につながります。
それらの課題は、ある程度まで仕組みで解決することが可能です。

Enumぽいものは、比較的スモールに導入できる上にととても便利なので、作っちゃいましょう or 既存のモノを導入しましょう。活用事例としてDTOのお話にも触れます。

// users.statusが3だったら仮登録状態
if ($user->status === 3) {
こんな光景を、見た事がありますか。

PHPにはEnum型はありませんがEnumを模した実装は多くあります。
Hirakuさんの記事は読んだことのある方も多いと思いますし (https://qiita.com/Hiraku/items/71e385b56dcaa37629fe) 、myclabs/php-enumは多くのパッケージで利用されています 。
過去に私も自作しました(https://speakerdeck.com/o0h/bye-bye-magic-number)。これはCakePHP3での事例ですが、作成・導入をした結果とした感想は「メチャクチャDXが上がる」です。どこであろうと似たような表現を同じインターフェイスで扱うことで、メンバー間の書かれるコードの均質性が上がりました。
また、EnumをDTOオブジェクトと繋ぎこむとその効果は更に拡大します。
例えば「DBから取ってきた値」「ユーザーリクエストで飛んできたjsonデータ」を自然に扱えるようになります。
dereuromark/cakephp-dto dereuromark/cakephp-dtoを利用しながら「どういう開発体験がもたらされるか」について考察します

平和な日々を送っていた企業に突然隕石が降ってきたら？
鶴の一声、メテオフォール型で始まったプロジェクト。

アジャイル、クリーンアーキテクチャ、DDD、マイクロサービス・・・

守られないスケジュール、失敗の数々。
モダン技術を取り入れたプロジェクトの行く末は？

それを乗り越えて生まれ変わっていく組織の姿をお伝えいたします。

「アプリケーションサーバでキューを処理していたが、キューの処理が重いのでキューを処理するだけのサーバを建てたい！」

AWS ElasticBeanstalkのWorker環境と、
キューを処理してくれる dusterio/laravel-aws-workerというパッケージを利用することで、
お手軽にキュー処理サーバできたよ！

という話をします！

PHPでAPIサーバーを作っていますか？
APIの仕様書は書いていますか？何を書いていますか？
たとえばJSONデータをPOSTするときに、JSONデータの仕様書も書いていますか？
APIサーバーをPHPで作り、フロントエンドをTypeScriptで作っていれば型を導入できますが、APIで送受信するJSONデータについて共通した型定義は導入できません(JSONスキーマを使っていれば別ですが)。
Protocol Buffersを使うことで、APIで送受信するデータに型を導入できるようになります。
このセッションでは、Protocol Buffersの紹介から、実際にPHPやTypeScriptでどのように使うのか、解説します。
※こちらはサンプルコード解説なしの短縮版となります

E2Eテストは"遅い"や"不安定"という理由で実施を諦めていませんか？
また、E2Eテストは大変すぎる、と思っていませんか？
おおくの現場でE2Eテストの範囲や実施内容に対する理解は、単体テストや結合テストと比べて曖昧になっているような気がします。
このセッションでは、Testing Pyramidと、その中でもE2Eテストの範囲や実施内容に対する理解を深め、どのようなツールを使うと良いのか？
といったプラクティスを解説していきます。

PHPでAPIサーバーを作っていますか？
APIの仕様書は書いていますか？何を書いていますか？
たとえばJSONデータをPOSTするときに、JSONデータの仕様書も書いていますか？
APIサーバーをPHPで作り、フロントエンドをTypeScriptで作っていれば型を導入できますが、APIで送受信するJSONデータについて共通した型定義は導入できません(JSONスキーマを使っていれば別ですが)。
Protocol Buffersを使うことで、APIで送受信するデータに型を導入できるようになります。
このセッションでは、Protocol Buffersの紹介から、実際にPHPやTypeScriptでどのように使うのか、サンプルコードを交えて解説します。

みなさんのアプリケーションはたくさんのライブラリの力を借りて実装されていると思います。
しかし、安易にライブラリに依存した実装をすると、ライブラリをアップデートしようとしても変更箇所が多すぎてなかなかアップデートできないなんてことがままあります。
では一体どうですればいいのでしょうか？ライブラリを使わずに実装すればいいのでしょうか？

いいえ、そんなことはありません。
このトークでは、ライブラリへの依存を極力抑えたままライブラリを活用する方法について解説します。

PHPのフレームワーク（LaravelやSymfonyなど）やテストスイート（PHPUnitなど）で利用できるアノテーション。とても便利な書き方ですが、実際どのように処理され、動いているのかあらためてご紹介します。さらに使いどころ、メリット・デメリットについても触れていきます。

エンジニアをしているとプロジェクトに途中からJOINすることはままあると思います。
前提条件はいろいろあるとは思いますが、
今回、新しいプロジェクトに途中からJOINしたので、
そのとき私がどのように切り込んでいったのかを共有したいと思います。

具体的には

• サービス概要をスコープを絞って把握する
• データベースの設計をスコープを絞って把握する
• 開発環境を手に入れる
• リポジトリの雰囲気を感じる
• ソースコードを読み解く

ということについてお話したいと思います。

本発表のゴールは、本発表をきっかけに「私ならこうする」「私はいつもこうしている」「私はいつもここに気をつけている」ということをみなさんが共有してくれることです。

途中JOINのノウハウを共有していきましょう！

現職にて、PHP アプリケーションを Go のアプリケーションに移行するタスクがふってきました。
現在のクライアントとのインターフェースを守りつつ、アーキテクチャなどを検討しました。
本セッションでは、そのときの検討過程や、実践した内容を共有したいと思います。
また、大部分は言語関係ない話になりますが、 PHP での実装と Go での実装に差が出たところにも触れたいと思います。

――勉強会を主催したものの、参加者が集まらない。
勉強会を主催する側として、このような状態はできるだけ避けたいものです。
地方で勉強会を開催する場合、首都圏とのエンジニア人口比率の違いもあり、メジャーなテーマでなければ人が集まらないことも…。
マイナーなテーマであっても、より多くの人にコンテンツを見て頂きたい…！
「日本中から参加者を集めれば良いのでは？」
運営チーム内でそんな声が上がりました。
あるエリアだけでは人が集まらなくとも、募集するエリアを広げれば、テーマに興味関心を持ってくれる人は増えるはず！
…とはいえ、遠方の技術系イベント・勉強会に参加するのって、交通費やら宿泊費やら、何かと大変ですよね？
「そうだ、リモートで多拠点から参加できるようにすればいいじゃないか」

リモート開催に関する物理的なノウハウなどは、さほど多く世に出回っていないようですので、
自社（東京・大阪の２拠点）で行っている、リモート勉強会で使用している機器・環境、進行ノウハウについて
ご紹介させて頂き、日本中・世界中のエンジニアの距離を縮めることに一役買わせて頂きたいと思います。