トーク

CI(継続的インテグレーション)してますか？

このセッションでは、CircleCIを使ったCIの構築事例と、テスト高速化やデプロイフローの効率化などのさまざまな工夫を紹介します。
「CIやってみようかな」「うちでもテスト高速化できそう」「え？こんな機能あったの？」といった学びがあれば幸いです。

工夫の一例

• テスト高速化・並列化・もっと並列化
• 確認ダイアログによる人力最終チェック
• PR自動マージによるマージ忘れ防止
• Gitのタグを見てフローを分岐

フレームワークのバージョンアップだとか、新しいコーディング規約の導入だとか・・・
コードをメンテナンスしているとどうしても避けられない「面倒くさい作業」ってありますよね。

その作業の一部で、よしなに機会がやってくれたらどんなに素敵でしょう？
PHPには、そんな「些細なリファクタリング」を手助けしてくれるツールが複数あります。
使いこなせれば、あなたのチームを「面倒」から解放してくれることでしょう。

このセッションでは、いくつかのツールを取り上げながら「仕組み・原理」と「活用・カスタマイズ」について紹介します。
具体的には、Rector, PHP CS Fixer, EasyCodingStandardを想定しています。

「一括してコードを綺麗にしたい」という人たちのために、「ツールの基本利用やオレオレルールの作成」までお届けして、退屈な仕事を減らす！！ことができれば幸いです。

みなさんはカンファレンスで登壇したことがありますか？
カンファレンスで登壇をしているスピーカーは、様々な過程を経てみなさんの前でトークをしています。例えば採択前ならネタ決めやプロポーザル、採択後ならスライド作成・トーク練習などの準備・・・
このトークするまでの過程は、人によって違うところもあり暗黙知であることが多いように思えます。

そこで今回は、過去に私がPHP系カンファレンスにて登壇した内容を例にしつつ、自分がカンファレンスで登壇するまでに準備していることを話します。
あくまで私個人の例ではございますが、少しでも登壇に対する暗黙知をなくすことを目的としてトークします！
まだ登壇したことがない方はもちろん、登壇したことがある人も良いところを取り入れられるきっかけになれば幸いです！

具体的には以下のことについて触れる予定です！
・プロポーザルを出す時にどんなことを考えているのか？
・無事採択されたけどトークするまでの準備はどういうことをしてるのか？
・過去に採択されたことのあるトークを例に具体例を紹介

トーク概要

コンピュータシステムの理論と実装という本を読んでおり，アセンブラの実装をすることになったので，アセンブラとはどのような機能を提供し，どのようにして実装をするのかという話をします．

コンピュータのソフトウェア階層の中で，最も基礎となるモジュールであるアセンブラを実装することによって，アセンブリ言語で書かれているプログラムがどのようにしてバイナリで書かれたプログラムに変換されるのか，その仕組みを広く浅く話したいと思っています．

トーク対象・分野

PHPでモノを作るのがお好きな方，なぜか知らないけれどPHPでモノを作ることにロマンを感じる方，低レイヤーがお好きな方

その他

大きなカンファレンスなどに登壇するのは初めてです．

多くの場所でジェンダーに関する話題が議論されるようになり、ITコミュニティでも無意識バイアス、ハラスメント対策などエンジニアの女性比率を高める為の取り組みに注目があつまっています。

これらの議論の中ではしてはいけない行動がなにかといったことが多く話題に上がる一方で、ではどのような行動をすればいいのか、また男性エンジニアの文化そのものについてはあまり話題に上がりません。

このセッションでは「男性エンジニア」とそれを取り巻く環境と文化とはどういったものなのかを考察し、より多くの人に対してインクルーシブなコミュニティや職場を作るために男性エンジニアがどのような行動を取れるのかについて紹介します。

トーク内で取り上げる予定の話題

• ロールモデル
• 無意識バイアス
• 心理的安全性
• Cultural Water
• アライシップ
• ジェンダーギャップ
• Michael Welp : White Men: Time to Discover Your Cultural Blind Spots
• Tony Porter: トニー・ポーター：男達への提言
• ジェラルド・ワインバーグ: プログラミングの心理学
• イリス・ボネット: Work Design

小学校でプログラミング教育が必修化される中、「Scrach」のような
ビジュアルプログラミングは注目されています

そんな中、LOVOT（https://groove-x.com/）と呼ばれる
『役に立たない、でも愛着がある” 新しい家庭用ロボット』がコンセプトの
ロボットに、「LOVOT STUDY ビジュアルプログラミング」という
ブラウザを用いてビジュアルプログラミングし、LOVOTを操る仕組みが提供されています

"ビジュアルプログラミング"でできることは、PHPでもできる！ことを
実証するために、
本来、ビジュアルプログラミングで操作するLOVOTを
直接PHPのプログラムから操作してみました(非公式)

まずは、ビジュアルプログラミングを解析する過程、そして
解析内容を元にPHP（Ampを用いて）で再実装する過程をお話しします

Let's PHP programming！

【トーク対象】
・AWS RDS を利用されている方

【分野】
運用、データベース

【トークの概要】
AWSのRDSでMySQLを利用されている方は比較的多くいらっしゃると思います。
MySQL5.6が2021年2月にExtended Supportが終了したのをご存知でしょうか。
Extended Support終了に伴い、RDSのMySQLも5.6が廃止されます（2021年8月に廃止でしたが、どうも難航しているようで2022年2月まで延期されました）。

RDSはマネージド環境であるため一見管理不要なように思いがちですが、メジャーバージョンアップなどでは停止を伴うメンテナンスが必要になります。RDSを利用するwebアプリケーションによりますが、ダウンタイムの発生で大きな影響が発生しうるので計画的に対応する必要があります。

本セッションでは、実際のMySQL5.5から5.6、5.6から5.7へのアップグレード対応の事例を紹介します。マネージド環境でもダウンタイムが発生しうること、ダウンタイムを0もしくはできる限り短くしなければいけない場合の対応方法についてお話します。マネージド環境であってもメンテナンスを続けていかなければいけないことをお伝えできれば良いなと思います。

Webサービスを運営していると、サービスからユーザーにせっかく送ったメールが届かないことがあります。
そのような、何らかの理由で目的のユーザーの元に届かなかったメール＝バウンスメールをどう処理するかは、サービスにとって避けては通れない課題なのではないでしょうか。
また、AWS SESを使っている場合、バウンスメールの数が多すぎるとペナルティがあったりするなど、サービスにとってバウンスメール処理は意外に大事なものだったりします。
このセッションでは、そもそもバウンスメールとは何なのか、バウンスメールを適切に処理しないとユーザーそしてサービスにどんな不利益があるのか、またBASEのバウンスメールの処理に関する知見と実際の実装について、お伝えしたいと思っています。

1番最初にOSSにPRを出した時に、皆さんは緊張されませんでしたか？僕はしました笑
PRを出すのはこの方法であっているのだろうか、的外れなPRではないだろうか…などなど。
このセッションでは、OSSにPR出すのにあたってまずは翻訳から参加することで心理的なハードルが下がったり、翻訳も案外勉強になってしまうことを、翻訳のtipsと共にお話しします。

クラウドファーストが謳われるようになっている現在、その利用を検討することは避けられないと思います。
このLTでは、自分のこれまでの経験から把握している、クラウド利用料金の抑え方のポイントをお話しします。
また、個々の施策の効果について、大きかった事例を優先的に、差し支えのない範囲でご紹介していきます。

[補足]
自分は現在フリーランスで、複数のLaravelベースなプロジェクトに参画していて、インフラ面を担当しています。
そのため、事業/案件規模に応じたコスト改善対応を経験しました。この背景が話の情報源になります。

みなさんのチームでは日頃からコードレビューはされてますか？
弊社でもリリースするコードに対して2人以上のコードレビューを必須にしたりと活発に取り組んでいます。

コードレビューには以下のような効果が期待できます
　・ソフトウェア品質の向上とアーキテクチャの統一
　・スキルの向上とナレッジの共有
いかに効果的にコードレビューを実施するかによって、チームの成熟度やプロダクトの品質に影響すると言っても過言では無いかもしれませんね。

しかし、正直なところ自分はコードレビューに苦手意識がありました。
一度のレビューに時間がかかったり、他のメンバーと比較してコードの改善提案をする回数が少ないのです。。。
そんな私が苦手意識のあるコードレビューをどの様に克服していくのか、体験談を踏まえてお話しできればと思います！（現在進行形）

▼お話しする内容
・苦手意識のあるコードレビューをどのように克服していったのか（体験談）
・チームの過去1年分のコードレビューを分析してみる
・ペアプロならぬペアレビューをしてみる
・とにかくレビューしてみる
などなど

LaravelのフォームリクエストのprepareForValidationでは
バリデーションを実行する前にリクエストデータを加工することができます。
リクエストデータを小文字に統一することや
[name=month value=10]、[name=day value=2]の2つリクエストデータを
[name=date value=102]という1つのリクエストデータにmergeすることができます。

ですが、prepareForValidationでmergeして新たなリクエストデータを作るとテストがしにくなってしまうのです。
基本は、Laravelのフォームリクエストをテストするとき、
Validatorファサードでバリデーションインスタンス生成して
passesメソッドに想定していデータを受け渡して確認するのですが、これが使えなくなるのです。

こういった場合のテスト方法として、以下の3つが考えられます。

1. Validatorファサードを使わず、自己流でバリデーションインスタンス生成してテストする
2. フォームリクエスト単位ではなくFeatureTestとして大まかにテストする
3. Laravel Duskを利用したE2Eテストで大まかにテストする

それぞれについて試した結果について話します。

本セッションでは主にLaravelのフォームリクエストとテストについて話します。

皆さんはスクレピングツールを実装しようと思い立った時のどの言語で実装しようと考えますか？
もちろんPから始まるお馴染みのあの言語ですよね！
PHPですよね！

スクレイピングするならPythonというのが一般的かもしれませんが、自分たちが慣れ親しんできたPHPでも十分にスクレピングができるということをお伝えしたいと思います。
PHPが優れてるよ、というお話はしません。好きな言語で好きなものを自由に作ってみよう！というスタンスでお話しさせていただきます！

"
巨大なレガシーシステムのPHPを8に上げました。その時に苦労した点などを中心に知見を一気に紹介します。
対象システムは20年運用されており、ノンフレームワーク、昔ながらのおおらかなPHPで書かれたシステムです。
いわゆる「ゆるふわ」なPHPで書かれており、しかも大規模なシステムははPHP8とは非常に相性が悪く、バージョンアップは非常に困難なプロジェクトとなりました。
レガシーシステムをPHP8に上げるために何が必要だったのか？躓いた点は？どれくらい手をかけたのか？など、実務で発生したことをお話します。
とくに、できたこと・できなかったこと・やらなかったことなど、実際のバージョンアップで役立つ要素を紹介します。"

昨今では数学の重要性が以前にも増して叫ばれるようになってきました。
AI やビッグデータの技術や人材をコア・コンピタンスに据える企業も増え、データ経営といった言葉も耳慣れるようになってきました。
近いうちにプログラマーと数学は切っても切れない関係になる、そんな時代が到来するやも知れません。

とは言え数学を勉強するのはハードルが高い、でも数学を活用したコードは書けるようになりたい。
そんな PHPer に紹介したいライブラリが MathPHP 。
このセッションでは MathPHP を使ってベクトルや行列、統計学を手軽に扱う方法を紹介します。

MathPHP: https://github.com/markrogoyski/math-php

皆様、LTは好きでしょうか？私は好きです。

日々の業務の中で、ちょっとした学びやTipsの共有、チームへの周知事項、くだらないことなど、その人がチームにLTを通して伝えられる知見はたくさんあります。
そのようなチーム内に埋もれそうになる知見を発表してもらうべく、LT大会を不定期で開催するようにしました。

「完成度低いの歓迎」と銘打つことで、良いことがあると感じました。
その取組について紹介します。

PhpStorm 使っていますか？
ご存知の通り、PhpStorm は、開発を効率的に進めるための機能がたくさん搭載されており、PhpStorm を使いこなして開発を進めている人の作業を見ると、素早いコーディングに驚かされると共に、自分も同じように PhpStorm を使い倒したいと憧れます。
しかし、一方でいざテクニックを覚えようとしても、何から覚えていけばいいかとっかかりがわからず、結局自身の知っている範囲でのショートカットやテクニックのみを利用してしまうといったことはないでしょうか？
このセッションでは日常の業務で役に立ち、かつ手をつけやすい PhpStorm のテクニックを段階ごとに解説し、徐々に PhpStorm エキスパートに近づく手助けをすることを目的とします。

$_GET["page"]、$_POST["name"]、$_SERVER ... PHP を初めて触った日、これらの変数を扱いませんでしたか？
これらの "スーパーグローバル" と呼ばれる変数は、初学時にこそ利用しますが、フレームワークを使い始めるとすぐに利用しなくなり、すでに忘れてしまった人も多いのではないでしょうか。
基本的にフレームワークの仕組みを使えば、これらの変数を利用する機会はない上に、中には設計上、セキュリティ上利用すべきでないとされている変数も含まれているため、PHP を扱っていてもあまり正面からスーパーグローバル変数を理解する機会は少ないと思います。
本セッションでは、PHP 初学者を対象に、スーパーグローバル変数をおさらいし、何気なく使わなくなったこれらの変数がなんだったのか、意外と理解していない使わなくなった理由について考えることで、PHP 初学者以降のスーパーグローバル変数との付き合い方を紹介します。

Composerには、Pluginという仕組みがあります。
Comopserに2.0が来るまでは、hirak/prestissimoにお世話になっていた方も多いと思います。(私もその1人です！！)

では、「どういうことが出来るのか」はご存知でしょうか。
「あの便利なComopserが、更に便利になっちゃうんですか？！」とワックワクな妄想をしてみたい・・・そのためには、まず「どういう事ができるのかな？」を知る必要があります。

知ることが全ての始まりです。
もしかしたら、あなたの仕事に革命を起こすような素晴らしい可能性が眠っているかもしれません。
(もちろん、「not for me!!!」と叫ぶだけの結果に終わる可能性もあります)

このセッションでは、「Composer Pluginとはなんだろう？」とイメージを掴むために、「どういう仕組みになっているのか」「どういう機能があるのか」を紹介したいと思います。

PHPウェブアプリケーションにおいて、データベースは不可欠な存在といっても過言ではありません。テーブル設計の方法論や、各種 RDBMS ごとの特性、チューニング方法の理解などを通して、データベースについて学んだ方も多いと思います。

本トークでは、ふと「PHPでデータベースを作ってみたら、もう少しデータベースと仲良くなれるのではないか？」と思ってしまった私が、データベースを作成していく過程で得られた知見について、発表します。

• データベースの基本構造
• なぜMySQLはB+木を使うのか
• インデックスとは何か
• 構造から考えるチューニングのツボ