トーク

「コミュニティ運営を通して、エンジニアとの繋がりを広げ、自己成長につなげたい。」
そんな思いで、私たちは、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 7 になってからいくつかの新機能がありましたが、その中でも型宣言については注目されていたのではないかと思います。
ただ、私の日々の作業の中に取り入れられているかと言われれば、その答えは No でした。
型宣言をすることで得られるメリットも複数あります。

そんな、あんまり PHP の型って使ってないし、いまいちよく分からないな、という型向けのセッションにしたいと思っています。

近年当たり前の用に使われれている、AWS、GCPを始めとしたパブリッククラウドサービス。
DevOpsの概念の浸透とともに、アプリケーションエンジニアでもインフラ層を触ることはしばしば見受けられるようになりました。
しかし、そんな中でも意識する機会が少ないネットワーク。
あなたは雰囲気で触っていませんか？

弊社でEKSを使用しkubernetesクラスタをAWS上に構築したのですが、その時にネットワーク周りの様々な制約が出てきました。
その時の問題点の解決策と登場する概念を踏まえ、AWSのネットワークの基本を紐解きます。

こんな方へオススメ
・EC2を立てるときは、デフォルトVPCを使っている
・将来的にAWS上にkubernetesクラスタを構築したい
・AWSにちょっと詳しくなりたい

普段AWSを懇意に利用している私がふとしたきっかけでAzure Functionsを利用する事になりました。

せっかくなのでAWS Lambdaとの勝手の違いをAWS エンジニア目線からお届けしようと思います。

PHPerKaigai2020が行われている頃には紆余曲折して悩み、苦しみ、答えを出している頃です。

その経験を赤裸々にお話しようと思います。

・想定する聴講者
　- Serverlessに興味のあるWEBエンジニア
　- AWSを利用しているクラウド系エンジニア
　- Azureに興味のあるクラウド系エンジニア

・お話する内容
　- AWS LambdaとAzure Functionsの違い
　- 構築するうえで感じたクラウドリソースの違い
　- Azure Functionsのメリット、デメリットの主観
　- 紆余曲折の内容を話せる範囲で

・お話しない内容
　- Azureゴリゴリのエンジニアに向けた話
　- Azure Functionsを利用する上での答え

‪https://github.com/rectorphp/rector は、既存のPHPコードのリファクタリングやアップグレードを自動実行するツールです。‬

‪フレームワークのバージョンアップをした、IDEを本格的に導入し始めた、新しいバージョンのPHPを使い始めた・・・開発を続けていると、色々な場面で「コードの書き方を変える必要が出て来た」「今までの書き方だと足りていない」という問題が発生します。かといって、膨大な量の(しかも退屈な！)書き換えを行うのは、なかなか気の進まない作業です。‬

‪rectorを利用すると、設定したルールに従い簡単な書き換えを自動的に実施できます！‬

‪ツールの概要や使い方、独自のルール作成の方法を紹介したいと思います。‬また、php-parserの動かし方についても言及しながら、「rectorは内部で何を行なっているのか？」というイメージを掴むことで、この不思議でパワフルなツールが皆さんにとって「怖くないよ！」といえるような、手助けになればと思います。

PHPUnitは、PHPソフトウェアのデファクトスタンダードとも言えるテストフレームワークです。それを利用して、どんなテストが書けるでしょう？
昨今のアプリケーションの開発は、より「責務」について重んじるようになり、それぞれの境界線を明確にする意欲が高まっているように感じます。そのため、開発者が「このテストは、何が出来れば(⇔何が出来なくて)良いんだっけ」を考えるのは正しい姿勢でしょう。

皆さんも、「モック」や「スタブ」が好きですよね。PHPUnitには、いくつかの「テストダブル 」の機能がサポートされています。このセッションでは、具体的なコード例を用いて、「やりたいテストを表現するための素敵な方法はないのかな」「どうしてこういう機能があるのかな」について考えてみたいと思います。

皆さん、Laravelは大好きですか？私は大好きです。
皆さん、オレオレフレームワーク使ってますか？私は使っています。

今やPHPでWEBアプリケーションを作るならLaravelが候補に挙がるくらいには有名になりましたが、それはあくまでも新規案件のお話。
今回ご紹介するのは、レガシーなPHPアプリケーションにLaravelを導入したお話です。

しかしながら、一言に導入すると言っても、それは簡単な話ではありません。
いきなり全部のコードを入れ替えるわけにもいきません。
既存のサービスを止めるわけにもいきません。
Laravelは導入するけど、既存の資産はそのまま使いたい…！
などなど、いろいろな要望や懸念があるかと思います。

そんな中、私が担当するPHPアプリケーションでLaravelを導入するために取った戦略とは…！？

本セッションでは、以下のことを実際の実装を見つつハートフルにお伝えする予定です。

• レガシーアプリケーションにLaravelを入れるまでの苦労話について
• どのようなハマりポイントがあったかについて
• Laravelのどの機能を使っているのかについて
• プレーンなLaravelと比べて制限される機能について

Laravelをレガシーアプリケーションに導入してみたい方、どんな構成になっているのか気になられた方、どなたでも構いません。
ご興味を持たれた方はぜひご参加ください！！

ドメイン駆動設計をどのようにして知ってもらい、文化を広めるというのは非常に難しいです。
色んな手法で広めていくと思うのですが、今回私が行ったのは「言葉と資料」で駆動設計をプロダクトに盛り込むことにしました。
今回はドメイン駆動設計を布教した一連の流れをお話できればと思います。

ドメイン駆動設計を社内で布教したい、実践でやってもらいたいという方へ一例として知見に貯めていただければと思います。