トーク

「より良くPhpStormを使うために、コーディング規約やテスト実行の設定をプロジェクトやチームで共通化しよう」

.idea/ ディレクトリを.gitignoreで無視するように設定しているレポジトリをよく見かけます。
もし”慣習的に”そうしているのであれば、勿体ないかも知れません！

普段の開発にPhpStormやInteliJ IDEAファミリーを利用している方も多いのではないかと思います。
高機能でありながら、「少しだけ」使う分にも充分に威力を発揮することには、ユーザーの皆さんも同意されるのではないかと思います。
他方で、「設定しなければいけない項目」も少なくないのも事実です。

Inspectionの設定、Interpreterの設定、テスト実行の設定・・・
これらを「PJメンバー全員で同期する」ことができれば、一気に効率が良くなります。
「生産効率」の水準が揃う、という手段となります。

そのための手段が「.ideaを共有する」なのです！！

どのように使えば良いのでしょうか？
また、それによってどこまで実現できるのでしょうか？

本トークを通じて紹介します！

phpinfoは、インストールする時によく使いますね。
それがどのように動いているのか知りたくなったので、phpinfoを写経してみて、わかったことを共有したいです。

単体テストを作り込んでいくと、「データベースを使う部分をどうするべきか？」という悩みにぶち当たる場面があると思います。
「そもそも”コードのテスト”なのにデータベースに依存するなんて」や「どうしても全体実行に時間がかかるな」などです。

そこで、「vimeo/php-mysql-engine」という選択肢はいかがでしょう？

前口上

丁寧に、クリーンな構造を持ったアプリケーションであれば、その辺りはモックやスタブを利用しながら、「データベース接続」についての一切の関心を外に追いやったテストも可能になるものかと思います。
他方で、「そこまで行っていない」アプリケーションも多いでしょう。
いずれにせよ、既存のアプリケーションやフレームワークといったコードベースに、大幅な手を加えず、それでも「もっとライトにテストを回す」という願望は叶えられないものか・・・

本題

vimeo/php-mysql-engineは、実際のMySQLデータベースを用いずに、(PDO_MYSQLを想定した)RDBMS処理を再現できるライブラリです。
vimeo/php-mysql-engine - Packagist

既存のアプリケーション構造が、リレーショナルデータベースと疎結合にできる”testable"な状態になっていなくても、
php-mysql-engineを利用すれば少ない工数で「自動化テストの効率化」を狙えるかも知れません。

このトークでは、ライブラリの簡単な紹介と、実際にテストに組み込むにはどうすればいいか？を紹介します。

皆さん、開発・運用では様々なツール、コマンドを駆使していると思います。
また、利用者もエンジニア、デザイナ、QAなど多様で、環境もローカル開発用PC、ステージング/本番サーバなど用途に応じてOS、プラットフォームを使い分けていることと思います。
そこで、makeコマンド(Makefile)で開発・運用をもっと楽にするための幾つかのノウハウを紹介いたします。

• 複雑な操作、一連の処理をまとめてタスク名をつける
• 必要なことだけをやる (依存関係、タイムスタンプ)
• 環境の違いを吸収する (開発/本番, Mac/Windows/Linux, etc)

※ phpに限定しない、汎用的に活用できるテーマです。

速いは正義、アプリケーションは速くあるべきです。

ではどうすれば良いのか

細かい理論などは気にしない、こうしたら早くなった

結果を貼り付けながら、何をしたのかひたすら話しますが、細かいことは話しません

事前収録であることを生かして、OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して
情報を詰め込むだけ詰め込むことに挑戦します。

※注釈は付けますので細かな理論はそちらでご確認ください

■想定する聴講者
　- PHPWebアプリケーションのパフォーマンスに興味がある方
　- PHPのインフラを整備するエンジニア
　- PHPでISUCONに挑戦する方

■お話しないこと
　- パフォーマンス以外の話
　- アプリケーションコードによる改善
　- 劇的なパフォーマンス改善策

ここ数年、フロントエンド技術は目覚ましい進歩を遂げてきました。私たちバックエンドエンジニアもその流れに追随するよう努めていますがなかなかにツライものがあります。なんとかバックエンドでインタラクティブな web アプリケーションが作れないものか…と考えているそこのあなたに朗報です。

Phoenix LiveView
Laravel Livewire
Hotwire

と各言語でバックエンドからインタラクティブなwebアプリケーションを作成するためのライブラリが立て続けにリリースされています。

本 LT では Laravel Livewire を中心に業界の動きを紹介します。

エンジニアにとって、エディタは毎日使うコーディングのお供であり、また、エディタの機能をうまく使いこなすことによって、作業効率は飛躍的に上がります。
しかし、我々はエディタを本当に使いこなせているでしょうか？
普段何気なく使っていると、詳しい人から思いがけない使い方や、便利機能を紹介されたり、
ふとした拍子に知らなかった機能を見つけた経験がある人は多いかと思います。
本セッションでは、メジャーなエディタである VSCode について、存在を知ってさえすれば明日から活用できる（かもしれない）、裏ワザ的な機能や、便利機能を、発表者の独断で紹介します。

自分は今、とある Laravel プロダクト２件で "Fargate 化" に取り組んでいます。
両方ともまだリリースには至っていませんが、現時点でも数多くの壁とぶつかり、
その度に乗り越えられたり躓いたりで一喜一憂を繰り返しています。

2021年3月時点での、この道のりで得たFargate化の意味や乗り越えてきた障壁を、
共有できればと思います。

一昨年、昨年とWebアクセシビリティの前提や概念についてたくさんお話してきました。
そろそろじゃあどうやって実装するんだという意見を聞いたり聞かなかったり。

PHPerでも一度は言われたことがある（？）「簡単でいいのでお問い合わせフォームを作って欲しいのですが。」「ここマウスカーソルがあたったときに説明が出したいんですが。」「ここにタブを用意して切り替えられるようにしたいです。」
ときにはJavaScriptか…と思いながら実装をしているかと思いますが、きちんと伝えるべきユーザーに伝えられていますか？
これまでのトークから一歩踏み出して具体的なWebアクセシビリティを意識した実装についてお話したいと思います。

本トークでは下記についてお話をします。
・Webアクセシビリティを意識した実装とは
・WAI-ARIAを用いた実装事例紹介

M1 Macって魅力的なPCですね
「でも開発環境としてつかうにはどうなんだろう」
と思っている方も多いと思います
M1 Macを用いて、ARM用の開発環境をつくるときにはまった話をしていきます
たとえば、
そもそも基本ライブラリを用意するところ（Homebrew)
PHP8のインストール（PHPBrewを選択）
Swooleの拡張のインストール（PHPBrewの拡張としてインストール）
のハマりポイントをおはなします

「コード生成？なんか難しそう。人力で頑張ってコード書いチャオ！」
なんていうふうに思ったことはありますか？
単純なPHPコードであれば結構簡単に生成できるんです。

コードが少なくてシンプルであることに越したことはないですが、
開発する対象やPHPの制約のために似たようなコードをたくさん作らなくてはいけないケースがあると思います。
そういう時に役に立つのがコード生成です。
PHPの基本的な機能を使ってお手軽にコード生成する方法を紹介します。

チームで開発する際には、プログラムの整合性を担保ためや一定のコード品質を満たすためにコードレビューを行うことがほとんでです。
社会人になって、自分の作成したコードをきちんとチェックされるという経験をする新卒エンジニアも少なくないでしょう。
最初は粗だらけのコードでも、上司や先輩のコードレビューをもらい修正することで、一定水準を満たした状態でアプリケーションに取り込まれます。
しかし、上司や先輩のコードレビューの手間や作成したコードの手戻りの手間を考えるとどうでしょうか。
コードレビューを受けて多くの指摘をもらったときに最初の内はなぜ指摘が多かったのかや、
今後、どのようにコード品質改善していったらいいかわからないという人も多いのではないでしょうか？
そこでコード品質を改善するために、どのような種類の指摘が多かったのかを振り返り、
セルフチェックリストの作成したり、ペアプロをおこなったりすることで
その結果、コード品質を向上させるために必要な観点を得ることができました。

社会人1~2年目でコード品質を改善する中で行ったことや気づきたことを紹介し、
社会人になったばかりの人や新しく社会人になる人の助けにしたい思います。

AWS ElasticBeanstalkで運用しているサービスでAWS SQSとLaravel Jobを用いたWorkerサーバーで不具合が発生した。

Jobの実行が必ず失敗するわけではなく、なにか特定の条件があった。
それはスペースが2個以上ある場合のメッセージQueueだと特定した。

この不具合に対してどのように改善したか説明します。

皆さんの開発現場はAPIドキュメントの自動生成化がお済みでしょうか？
このLTではCakePHP4にSwaggerを導入して、コードのアノテーションからドキュメントを自動生成するまでの流れをご紹介いたします。

▼こんな方におすすめ
・これからWeb API開発を始める方
・ドキュメント書くの面倒な方
・実装とドキュメントの乖離に苦労したことがある方

昨年、社内で実施した勉強会のテーマの中で一番メンバーの反応が良かったのが「アノテーションからのドキュメント自動生成」でした。ドキュメント作成の手間を少しでも減らして、開発体験を向上させていきましょう！
（LTではCakePHPをサンプルコードとして紹介いたしますが、Laravelに導入する手順も別途資料をご用意させていただく予定です。）

Advent Calendar（アドベントカレンダー）、以降アドカレと呼称します。
エンジニア界隈の人なら聞いたことがある人が多いでしょう。
エンジニア界隈でいうと12/1~25に記事を投稿していくイベントです。

僕が所属している組織では6年連続でアドカレを実施しています。
私は実施1年目からの発起人です。
はじめは人が集まらず1人でいくつも記事を書いてなんとか25個埋めていました。
運営として代表としてこれではいけないと思い
・地道な声掛け
・せっかく参加して投稿してもらった記事はしっかり読んで感想をFB
などコツコツ続けた結果6年も続けることができています。

・どんなキッカケで開始されたのか
・アドカレを行なうメリット、デメリット
・6年やって見えてきたもの
・これからやってみようと思う人と団体にアドバイス

このあたりを中心にお話できればと思います。
みんなアドカレやろうぜ！

自分はこれまで、いくつかのバージョンアップを実行してきました。

• PHP 7.2 -> 7.4 、7.3 -> 7.4
• Laravel 5.6 -> 5.7 -> 5.8
• PHPUnit 5 -> 6 (-> 7 -> 8 -> 9)

Docker の利用により以前よりは格段に難易度は下がっているように思うものの、
躓いたポイントや乗り越えた事例をいくつかお話しできればと思います。

PHPUnit もバージョン 9 になりました。長年第一線で活躍し私達PHPerにテスト可能な開発環境を提供し続けてくれているPHPUnitは、その分歴史が長く、バージョンごとに これまでの使い方は deprecated になっていきます。

PHPUnit 9 では、さまざまな機能削除や非推奨勧告がありますが、その一つが表題にある MockBuilder::setMethods の deprecated です。

そこで改めてこの変更を機に、次の点を抑えていきます。

• PHPUnitのTestDoubleの語彙整理の根拠 xUTP本とその該当箇所、createStub / createMockの違い
• setMethodsからaddMethods/onlyMethodsになった使い方
• deprecatedになった理由をissueの内容から抑えて背景思想を理解する
• PHPUnit の内部実装ではどのような変更が行われたのか（これはPHPUnit 8でのaddMethods/onlyMethodsの話でもある）