PHPer Kaigi 2019 に参加したので自分用メモを公開する #1

はじめに

今回、3月29日〜3月31日にかけて PHPer Kaigi 2019 に参加してきたので、そのレポートを書こうと思います。 phperkaigi.jp

カンファレンス内のイベント?に「PHPer チャレンジ」というものがあり、思いの外上位になってしまったので、維持するためにもブログを書きます。
(本当は普段は毎週月曜日に書いているのに、トークン欲しさに...)

とりあえず今回は何を聞いたかの自分用のメモ程度にしようと思います。
そのため、内容はほぼありません。

※私の言葉でメモしているので解釈違いがあるかもしれません。

3月29日 前夜祭

15分で分かった気になるGraphQL

トーク
15分で分かった気になるGraphQL by 市川 慎吾 | プロポーザル | PHPerKaigi 2019 - fortee.jp

GraphQLのお話

クライアント・サーバ間で型安全なコミュニケーションができる
GraphQLはファイルアップロードやエラーハンドリングは苦手
RESTと使い分けると良いかも→共存できる
Larvalならlighthouseっていうのがある

PHP でも Raspberry Pi がしたい!

トーク
PHP でも Raspberry Pi がしたい! by 東雲 | プロポーザル | PHPerKaigi 2019 - fortee.jp

Raspberry PiPHPを使ってみるお話

Lチカはシェルから叩ける→echo+リダイレクト→つまりphpならfile_put_contentsでいける!
PHPからGPIOを制御するライブラリがある PHPでやる理由→webから操作できる(PHPerだから)

「質」の良いユニットテストを書くためのプラクティス

トーク
「質」の良いユニットテストを書くためのプラクティス by 東口和暉 | プロポーザル | PHPerKaigi 2019 - fortee.jp

テストのお話

なぜテストを書くのか→コスト削減

ユニットテストによるコスト削減 vs ユニットテストの作成・維持コスト
テストの経済性(非経済性)→維持コストが低ければ最終的にトータルコストが下がる(逆もある)

・意図を伝えるテスト
test as documentation
読み手を意識する
大事なのは「テストを書くこと」ではなく「テストをすること」
・テストを独立させる
SUT(System Under Test: テストしている対象を示す)に対して疎結合
SUTをブラックボックスとして見る
テスト間の独立性
相互依存・順序依存しない
fixture→1回で設定できるから便利だけど依存する
共有&専用fixture 通常ユーザ&利用禁止ユーザ
・重複を最小限に
テストでもDRYが大事
テストファーストによってテスト容易性が強制される

「テストを書く」ことは簡単
費用対効果の高いテストを目指すのは考えて実践する必要がある

3月30日 午前の部

フレームワークを作りながらLaravelのアーキテクチャを学ぶ

トーク
フレームワークを作りながらLaravelのアーキテクチャを学ぶ by endu | プロポーザル | PHPerKaigi 2019 - fortee.jp

フレームワークを作って本質を知るお話

HowではなくWhyを習得する
FWつくってみた
→楽しい!
→自分が好きな機能をすぐつけられる万能感
→オートロードやルーティングやviewの仕組みが理解できた
→名前解決方法が重要

デバッグ eval(\Psy\sh())

DIとは
DIコンテナとは
サービスコンテナとは
ファサードとは

How(手段)ではなくWhy(本質)を求めて、良いエンジニアへの一歩へ!

抽象化って何?

トーク
抽象化って何? by 後藤 秀宣 | プロポーザル | PHPerKaigi 2019 - fortee.jp

抽象化の抽象的なお話

現実世界の抽象化とは?
プログラミングの抽象化とは?
指針を知り、良し悪しを判断できるように

抽象にはレベルがある
抽象レベルがあがると特徴量をは減るが対象は増える
レベルが揃ってないとコミュニケーションができない

プログラミングにおける抽象化とは、interfaceやabstract classを使うことではない

指針は?
適切な命名
抽象度の統一
狭い範囲

依存関係の本質を見極める

抽象化には方向性があって、物を見るときの視点で変わる どの視点で見るかという意味で「モデリング=抽象化」

3月30日 ランチセッション

(ランチをゲットできず、ランチの旅に出ていました)

3月30日 午後の部

MySQLにWEBアプリのログを保存しているケースの8割くらいが幸せになる方法

トーク
MySQLにWEBアプリのログを保存しているケースの8割くらいが幸せになる方法 by yoku0825 | プロポーザル | PHPerKaigi 2019 - fortee.jp

ログ by MySQLのお話

そのログは本当にRDBMSに保管し続けるのが幸せなのかを見つめる
外に逃がすことを考える

グレコードか否か→insert以降updateがない&制約がない
グレコードかどうかで扱いがぜんぜん違う
ホットログ vs コールドログ

RDBMSのメリット
→簡単に使える
トランザクション便利
RDBMSのデメリット
トランザクションの保護のための仕組みが重厚すぎる

RocksDB 時系列データベース

MySQLにデータが入ってることが幸せ
→がんばればMySQLだけでいけるw

設計力を上げるバリエーションの見極め術

トーク
設計力を上げるバリエーションの見極め術 by 77web | プロポーザル | PHPerKaigi 2019 - fortee.jp

バリエーションを想像するお話

バリエーションとは→プログラミングにおいては処理が分岐するきっかけになる
なぜバリエーションが発生するのか→ビジネスが変化するから
ビジネスの変化のパターンを見極めれば、バリエーションが見極められる

横の変化
本とトイレットペーパー
→どちらもamazonで買えるが必要な情報が違う
ポーションとハイポーション
Google AdとYahoo Sponsored Search
⇒これらはあとから種類が増える
⇒同種の別のものを扱うことはないか?と想像する

縦の変化
消費税や年号
→時系列で変わる
⇒過去の歴史から想像する
⇒他国の先行事例から想像する

業務知識をつけないと想像力がただの妄想力になる

早すぎる最適化にならないか
→防ぐためにも業務知識を付けつつ慣れが必要
最初はif-elseの2値にして、増えてから改めてバリエーションを見極める

たった1人のAPI開発 BEAR.Sundayで解決した課題たち

トーク
たった1人のAPI開発 BEAR.Sundayで解決した課題たち by 斉藤裕気 | プロポーザル | PHPerKaigi 2019 - fortee.jp

API開発のお話

(事前に知っていたのでメモ無し)

プロダクトを作って終わりの時代ではない!

ショートカットリソースを使ってサーバサイドとして困ったことは?
→リソースが404かどうかの判定に悩んだ
→主のリソースを選んでそれが404なら404なんだと考えてサーバ側で分岐した

RESTの力

トーク
RESTの力 by 郡山 昭仁 | プロポーザル | PHPerKaigi 2019 - fortee.jp

RESTの本当のお話

(感動して聞き入ってほぼメモ無し)

RESTとは全てを結ぶ力

リンクされていたらリンク先が終了したときにシステムとして破綻するのではないか?
→オープンデータとクローズドデータという考え方がある

サーバーレスPHP

トーク
サーバーレスPHP by 角田 一平 | プロポーザル | PHPerKaigi 2019 - fortee.jp

Lambda+PHPのお話

メリット
→管理・設定・更新をする必要がない
→用意しなくていい
→安価

向いてる
API Worker/Batch 処理が短い with Dynamo
向いてない
→Webサイト レスポンス大きい with RDS with VPC (コールドスタート?)

sam deploy

symfonyはつっこめるけどまあまあめんどくさい、はずだった →Brefを使うと簡単

pythonでええやん→PHPerだし学習コストががが

PHPerのための計算量入門

トーク
PHPerのための計算量入門 by 富所 亮 | プロポーザル | PHPerKaigi 2019 - fortee.jp

計算量のお話

2つの計算量
時間計算量
空間計算量

in_arrayからarray_key_existsに変えればいいわけではない
データ量と計算量からどうするか考える

さいごに

前夜祭と1日目を楽しんできました。
遅刻したのでランチをゲットできなかったのが心残りです。
2日目はランチをゲットするのが目標。

トークン欲しさのブログでした...