トーク

プロダクト開発に置いて、様々なデータを集め、取得し、分析、活用していくのが当たり前になってきました。
しかし専属の分析担当/チームがある会社もまだ多くはないかもしれません。

そういった場合に取得と分析を誰がどうやっていくのかがいいのでしょうか。

例えば下記のようなケースもあるかと思います。

• エンジニアが分析担当を兼任し、ビジネスサイドは関与しない
• ビジネスサイドから欲しいデータの抽出をエンジニアに依頼、ビジネスサイドが分析していく

私達はスピードと柔軟性のためにビジネスサイドもエンジニアも一緒にやっていくことを選びました。
それを実現するにはビジネスサイドもSQLを活用できないといけません。

ビジネスサイドとエンジニアが協力をして実際にどういうことを行ったか、
ビジネスメンバーはどういうことからはじめて、どれくらいのことができるようになったのか、エンジニアとどういう分担をしているのか、
そしてそれらを行っていく中でうまくいった点や改善点についてPHPerのエンジニアが話します。

※ 具体例としてDBはBigQuery,データはFirebaseで収集したアプリのイベントを使います。

想定する聴講者

• 経験や職種関係なくSQLを活用して、データ抽出を行いたい、ダッシュボードを作りたい方
• SQLの活用を他のメンバーにも広めたいエンジニア

話さないこと

• PHP
• 分析の詳細
• SQLの詳細の文法

2019年11月、GitHub Universe 2019で「GitHub Actions」がついに正式版になったことが発表されました。
これまではベータ版として公開されており、v1, v2と大きな仕様変更を経て正式版公開となったわけですが、興味はあるもののしっかりとキャッチアップできている人はまだまだ多くないのではないでしょうか？

本トークではGithub Actionsを1から解説し、実際にこれまでCircleCIやTravisCIで行っていたPHPアプリケーションのCI/CDを、Github Actionsを利用して実現できないかを検証します。
Dockerコンテナを活用しつつ、PHPUnitによるテストや、phpcs・phpstanといったQAツールを実行する具体例として参考となるものにできればと思います。

先日、18年間運用されているシステムで大量のユニットテストを書きました。その際大量のモックを利用し、必死にコードの動作を制御するという経験をしました。
そこで得られた知見を整理すると、ぼんやりとクリーンアーキテクチャにつながる出口が見えてきました。
なぜモックを書かなければならなかったか、大量生産したモックはいったい何を意味するのか。
モックを使うことでテストを通すだけでなく、モックを利用して設計を改善する方法があるということをご紹介します。

いわゆるレガシーシステムを運用していくにあたって、ユニットテストをどう書いていくべきでしょうか。
長大な関数、引き回されるグローバル変数、オブジェクト指向へのチャレンジの痕跡・・・このようなコードのユニットテストを単純に書くのは至難の業です。
先日、18年にわたって運用されているシステムで重要機能のカバレッジを100%にするというチャレンジを行いました。
その際に、ユニットテストとモックを駆使して問題を分割していくというアプローチを取り、一定の成果を得ることに成功しました。
今回はこのチャレンジで得た知見から、テスト手法の紹介と、今回取ったアプローチを突き詰めた先の展望についてお話します。

昨今では、アクセシビリティというキーワードを耳にすることが多くなってきました。
Webアクセシビリティとは、Webコンテンツに誰もがいつでもどこでもどんな状況でもアクセスができるようにしていくことです。

Webアクセシビリティは、デザイナーやフロントエンドエンジニアが取り組むものと思われがちですが、サーバーサイドエンジニアでもできることはあります。
私たちサーバーサイドエンジニアは何ができるでしょうか？

Webコンテンツをアクセシブルにするための指標に、Web Content Accessibility Guidelines (WCAG)というガイドラインがあります。
WCAGには、コントラスト比や画像の代替テキストなどが挙げられていますが、そもそもWebコンテンツが表示できるかどうか、レスポンスが遅すぎないかどうかなどの必須条件に関しては言及されていません。

このトークでは、Webアクセシビリティを支えるためにサーバーサイドエンジニアができることにフォーカスを当てて話します。

静的解析はプログラマにフィードバックを最も早く返す仕組みの一つで、コード品質をチームで高める際にも非常に有用です。
しかし、既存のプロダクトに対し静的解析をただ導入した場合、対応しきれないほどのエラーやワーニングが表示されるだけで、コード品質向上への効果が薄くなってしまいます。
本トークでは既存プロダクトにPhanやPhpStormのInspectionといった静的解析ツールを導入し、その後コードの品質向上効果を高めるために、静的解析を育てていった一部始終をお話しします。

パフォーマンス・スケーラビリティ・開発・運用、
これら多角的な観点から「マスタデータ」を考えます。

都道府県マスタ : 1:北海道／2:青森／3:岩手／4:宮城 …
金融機関コード : 1:みずほ銀行／5:三菱UFJ銀行／9:三井住友銀行 …
ポケモン一覧 : 1:フシギダネ／2:フシギソウ／3:フシギバナ／4:ヒトカゲ …
カテゴリ一覧 : general:一般／social:世の中／economics:政治と経済 …

変わらないデータでしょうか？変わるデータでしょうか？変わるとしたらいつでしょうか？運用するの誰でしょうか？

データの特性を捉えた適切な実装により、開発と運用の双方を効率化できます。その方法をご紹介します。

突然ですが「良いコード」とはどういうコードでしょうか？正解は一つではありませんが、私は「複雑さ」（Complexity）が見えないコードが良いコードだと考えています。複雑さが見えないコードはインターフェースが直感的で、リーダビリティが高くて、変更が容易です。
では、複雑さが見えないコードを実現するにはどうすればよいでしょうか？そこで登場するのが「deep module」という考え方です。「deep module」はスタンフォード大学のJohn Ousterhout教授が『A Philosophy of Software Design』という書籍で提唱しているモジュール設計の考え方です。
本セッションでは「deep module」とは何か？deep moduleを実現するにはどうすればよいか？という疑問をPHPのコードを用いて可能限り具体的に解説したいと思います。「deep module」を理解すれば、きっと今よりも「良いコード」が書けます！

注)この話はフィクションです。きっと。

■対象
・今最新を使っている人(メインターゲットです)
・これからやる人
・もうやって、あるある話を聞いて涙したい人

皆さん、バージョンアップしてますか？
PHPや、Laravel、古くなってきたからバージョンアップしよう。
よくある話ですね。

でも、何も考えずにプログラムを書くと、あとで痛い目を見ます。

これは、本当にあったかはわからない、バージョンアップで悲しみを背負った人の話。

■内容(変更あるかもしれません)
・vendor配下をいじった報い
・コードをコピペで拡張した悲しみ
・Laravelを見捨ててPHP上げたらLaravelがお亡くなりに
・テストコードなんてなかった
・このライブラリはもう居ない
・消えた機能
・見つからない変更点
・再度襲いかかるコピペの悲しみ

静的型付言語なら、こんな苦労はしないで済むのに！
そう思った経験は、ありませんか？
それを強く感じたため、PHPに変わる何かを探し始めました。
そして、以下の5つのチャレンジを行いました。

• チャレンジ1: Scalaを使ったチャットシステム
• チャレンジ2: Haskellを使った大陸間レプリケーションバッチ
• チャレンジ3: goを使ったメディアサービス
• チャレンジ4: pythonを使った推薦システム
• チャレンジ5: Kotlinを使ったカンファレンスアプリ

これらのチャレンジを通じて、どのような成果を達成できたか、そしてPHPと比べて良かった点と悪かった点について発表します。

PHP でも「型」に関する議論が盛り上がっている今、一度「型」についておさらいしてみませんか？
近年、主要なプログラミング言語の「型」を取り巻く環境が変化しています。もちろん PHP も例外ではなく、7.0 以降「型」に関する機能を強化しています。
PHP では型ヒントの強化や、Java ではローカル型推論が導入されるなど、さまざまな言語で「型」に関する機能が拡張されています。
この拡張の傾向としては、動的型付け言語(PHP, Python)は漸進的型付けを導入する、静的型付け言語(Java, C#)は型推論を導入するというのがよくみられます。
その結果、言語の型付けの方式に寄らず、必要な個所に型を記述するというスタイルに収束していきそうな気配すらあります。
しかし、両者の間で「型」そのものの扱いには明確に差があります。その差とは何でしょうか？その差は何をもたらすのでしょうか？
そして、PHP 上で「型」と向き合う時が来たとき、どのように付き合っていくのがいいのでしょうか？
このセッションでは、両者の「型」の進化をおさらいしながら、PHP がこれから「型」と付き合っていく上で得られるものや課題、PHPer が「型」とうまく付き合っていくための基礎知識についておなしします。

「コミュニティ運営を通して、エンジニアとの繋がりを広げ、自己成長につなげたい。」
そんな思いで、私たちは、2019年1月から、特にジャンルを問わない「もくもく勉強会」コミュニティを立ち上げ、9月までにのべ100人超の方に参加して頂くことができました。
10月からは、それまでの「もくもく勉強会」をやめ、「PHPを主軸としたWeb開発に関する勉強会コミュニティ」として再始動をしています。
本セッションでは、私たちが、なぜスタイルを変えてコミュニティを再始動するに至ったか、どのように変えたのかという点に触れつつ、これまでコミュニティ運営をやってみたうえでの、気づき・学び、安定したコミュニティ運営のためにやっていることなどをご紹介します。

ユーザ投稿型の音声配信サービス内のひとつの機能として、あるユーザにとって好きな投稿をレコメンドすることになりました。
分析の結果、「好きな投稿＝よく聴く投稿に似ているもの」であるだろうと仮定し、似ている投稿とは何なのかの研究が始まりました。
投稿データは音声の波形データであるので、その音声データを解析して特徴ベクトル化し、それを用いて似ている投稿を学習により推定することにしました。
そして最終的に、音声知識が皆無である中、音声データの解析手法やベクトル化手法とその実装について試行錯誤し、最終的にはサービスにそのまま組み込むのではなくGCP上でマイクロサービス化することで疎結合なシステムを作り上げました。

これは、Pythonを用いて、音声知識がゼロの状態から、数多の音声データを聴き様々な手法を試し学習させマイクロサービスを完成させた、PHPerによるトークとなります。

具体的には以下のような内容を予定しています。

• 音とは何か
• 「似ている」とは何なのか
• どのような解析手法を使ったのか
• どのように特徴ベクトル化しているのか
• どのような学習をさせたのか
• 最終的にどのようなレコメンドになったのか
• 設計・マイクロサービスについて

基本的にPythonを使って実装しており、PHPの話は一切出来てきません！

想定している対象者

• 音声解析に少し興味がある
• 機械学習に少し興味がある
• マイクロサービスに少し興味がある
• Pythonが好き

話さないこと

• 音声解析の本格的な理論
• 機械学習の本格的な理論
• PHP！

新規サービスの立ち上げに伴い新しいチームが発足しました。
これまではデータベースの設計であったりAPIエンドポイントの設計であったりはもちろんしっかりとやってきましたが、恥ずかしながらアプリケーションコード自体の設計はしっかりとはやってきませんでした。
ファットなコントローラーにテストも不十分という環境が当たり前のなか、新しいチームでの開発が始まるにあたり、せっかくなら良い設計のサービスにしようと思いたちました。
設計指針として様々な選択肢がありますが、今回はクリーンアーキテクチャを採用することにしました。
私自身も含めて設計に明るいメンバーはおらず、リリース日も決まってしまっているなかで、新たな「設計」を取り入れることをチームに受け入れてもらうために奔走し、挑戦しました。

これは、ひとりの設計初心者であるPHPerが、設計初心者チームに受け入れてもらうために取り組んだことに関するトークとなります。

具体的には以下のような内容を予定しています。

• なぜ「設計」に挑戦しようと思ったのか
• 設計で何を解決したかったのか
• なぜクリーンアーキテクチャを採用したのか
• どのような設計にしたのか
• チームメンバーに受け入れてもらうために取り組んだこと
• 取り組みとして成功したことと失敗したこと
• 設計に挑戦して良かったこと
• チームで設計に挑戦したその先

チームに受け入れてもらうために行ったことがメインで、設計手法自体はサブになる予定です。
PHPの話も少しだけ出てくると思います。

想定している対象者

• 設計を取り入れたいと悩んでいる
• レガシーな環境に辟易している

話さないこと

• 詳細な設計論

「PHP の仕様は RFC によって決められている。」これは PHPer ならご存知かと思います。
技術ブログや Twitter でときどき取り上げられる RFC ですが、実は自分で読んだことがない方は多いのではないでしょうか。
RFC は大抵の場合、我々より PHP に精通した人が提案し、議論し、要否を決定しているため、RFC を読み、その提案理由を考えることは、PHP 上級者への一歩です。
しかし、RFC は英語で記述されていますし、そもそもの仕組みを理解していない場合はどこから手をつけていいのかわからないなど、ハードルが高くないでしょうか。
本セッションでは、そんな PHP の RFC について、他の言語とも比較しながら、仕様が決定されるまでの基本的な仕組みや、読み方を紹介します。

働き方改革、すすんでますか？
子供がいると、どうしても母親に無理がかかってしまいがちですよね？しかもシングルマザーという不利な境遇。
そんな中、わたしは約1年前に転職してから、かなり柔軟な働き方ができるようになりました。
子供がいて全国各地に飛び回りながら楽しく仕事をしている母さんエンジニアはいったいどんな働き方をしているのか？

小難しいソースコードの話は出てきません。
女性も男性も、子供がいる方もこれからと思っている方も、まだまだ自分には子供なんてムリなんて思っている方でも、休憩がてら聞きにきてください。

OpcacheはコンパイルされたPHPのソースコードを共有メモリにキャッシュすることで、PHPの実行スピードを上げてくれる拡張です。現在のほとんどのPHPアプリケーションはOPCacheが有効化された環境で動いていると思います。さらに、PHP7.4ではOpcacheのpreloadが導入され、OPCacheは今後ますますの活躍が期待されています。

本トークでは、このOPCacheの仕組みを基本から解説することで、どのようにPHPの速度向上が行われているのか、また各種設定値がどのように速度に影響するのかを解説します。OPCacheの中身が知りたくてしょうがない方々に贈ります。

PHP 7.4からFFI(Foreign Function Interface)拡張が導入可能になりました。FFIによりネイティブの共有ライブラリ呼び出しが簡単になったので、PHP-GTKと組み合わせることで、PHPでデスクトップアプリケーション作成が捗ります。

本トークでは、PHP-FFI、PHP-GTKの簡単な使い方から解説して、PHPでもデスクトップアプリケーションが作れる！そんな可能性をお見せできればと思います。

もしも、PHPのソースコードが読めたら....。var_dumpがどんな風に実装されているのか、explodeはどのように動いているのか、Closureオブジェクトの実装はどうなっているのか？そんな疑問を、自分で直接見て理解することが出来るようになります。 でも、いざ読もうと思っても、C言語のソースコードを読むのは難しそうだし、そもそもどこから手を付けていいか分からないです。

本トークでは、PHPのソースコードを読みこなしていく方法を、手順化して丁寧に解説します。PHPのソースコードを読むことが、一部玄人の特権ではなく、誰でも出来るんだと感じていただきたいです。

プログラミング言語を実装したことはありますか？

本トークではPHPでPHPを実装していくことで、プログラミング言語が動く仕組みを紹介していきます。
静的解析でもよく利用されているnikic/PHP-Parserを使うと、字句解析・構文解析をパスして処理部分に集中してPHPを実装できます。
PHPを再実装するだけではなく処理内容を変えて「自分だけのPHP」を実装することもできちゃいます。

また、プログラムを表現するオブジェクトであるASTを扱えるようになると、静的解析などWebサービス開発の幅も広がります。
例えば、PhanやPHPStanなどの静的解析ツールやそのプラグインを自作できるようになったり、より堅牢なPHPの世界を作ることができます。

本トークではプログラミング言語を実装する楽しさを伝えるとともに、ASTに慣れ親しむきっかけになれば良いと思います。