拙い気持ちのアウトプット

私の気持ちをアウトプットする場所にしようと思っています

X-Tech JAWS & JAWS-UGアーキテクチャ専門支部 コラボ勉強会#01 に参加して

jawsug-arch.connpass.com

こちらの勉強会に参加してきました。

CI/CD・パイプラインといったテーマが中心でした。

特にわかり味が深かったのが、やはりビジネスサイドや開発メンバーの理解を得るためにどうするかといったところでした。

リファクタリングとかでもそうですが、表面的に見えない部分のエンジニアリングをどう理解してもらうかというのは永遠の課題なのかもしれないなと、改めて感じた次第です。

以下メモを残しておきます。

X-Tech JAWS & JAWS-UGアーキテクチャ専門支部 コラボ勉強会#01

2019/5/29

X-Tech（エックステック）

AWSなどをハブとして用いるFin-Tech, HR-Tech, Health-Techなど

xTech（クロステック）

X-Tech同士のメッシュ

AWSを使っていて、技術とあまり縁がなさそうかつ尖ったことやってそうな企業にオファーしました

jawsdays2019.jaws-ug.jp

JenkinsからCI/CDをはじめてみた結果

@ユニオンテック株式会社 井上 心太さん

建設xテック

建設業は自動車業についで国内第二位の市場規模！！！

発注者x受注者の間で情報の非対称性が起きている

「仕事受けてくれる人が見つからない」x「仕事がない」

ITでマッチングを解決（toBもtoCも）

jawsdays2019.jaws-ug.jp

  • アプリと管理画面を別々にデプロイしたい
  • 勝手にデプロイしたくない
  • テストはない

Jenkins

  • 単体ではできることが少なく、プラグインがけっこう必要
  • Groovyの保守が大変

今日からはじめるCI/CD…のためのAWSアーキテクチャ事始め (その後のアップデート)

@JAWS-UGアーキテクチャ専門支部 波田野 裕一さん

パイプライン

開発環境 ソースコード ビルド&テスト デプロイ プロダクション
CodeCommit CodeBuild CodeDeploy EC2/ECS/S3/Fargate/Lambda/etc

自分たちのパイプラインを論理的に説明できる必要がある！

最初にパイプラインの両端を検討

CI/CDデザインマップ

エンジニアの快適さ（開発環境）とサービスの快適さ（プロダクション環境）が優先

ビルドとテストは前後するはずなので、レイヤーとしては統合しとく

至高の CI/CD パイプラインを実現する5つの約束

前半

@ポジティブな Toriさん

最高のパイプラインを手に入れるためのマインドセットとは？

  1. パイプラインファースト
  2. 自動化されたパイプラインの維持
  3. 柔軟なパイプラインの維持
  4. パイプラインUXの継続的改善
  5. パイプラインが唯一のリリース手段

1. パイプラインファースト

  • アプリケーション開発から始める
  • CI/CDが後回しになる
  • だんだんデプロイが遅くなる

最初にパイプラインを作る 圧倒的な低リスク投資！

ちゃんとしとく必要はない お手製のスクリプトでも良い

知見がない場合は、まず手動オペレーションをなるべくスクリプト化するのを大事に

2. 自動化されたパイプラインの維持

ビジネス要求に応じたアプリケーションの変化

  • 自動化が難しくなる変更を避ける
  • ビジネス要求への対応方法がそれしかないか何回も考える
  • 他の実装方法がないか何回も何回も考える

大事なこと

  • パイプラインをシンプルに保つ（アプリケーション都合の複雑性を持ち込まない）
  • 一番複雑性を吸収しやすいのはアプリケーション
  • 後方互換性を持たない変更はNGというポリシーにする、とか

3. 柔軟なパイプラインの維持

大事なこと

  • パイプラインをシンプルに保つ（アプリケーション都合の複雑性を持ち込まない）2回目
  • Pipeline as a Code (Git)
  • Application / Pipeline / Infrastructure

4. パイプラインUXの継続的改善

パイプラインは開発メンバーへの「サービス」である

良くないこと

  • 何が起きてるかわからない
  • 時間がすごいかかる（黒魔術化は注意）
  • 不安定

5. パイプラインは唯一のリリース手段

こんなことは（なるべく）やらない

  • なんかテスト通らない
  • なんかビルドできない
  • 急ぎだから

後半

@株式会社サイバーエージェント 小西 宏樹さん

なぜパイプラインは神なのか

Context

  • Webアプリケーション開発現場
  • マイクロサービス
  • Serverless
  • AWS
  • スピード重視
  • 密結合
  • 運用レベルのばらつき

現場の課題

  • 無停止デプロイできない
  • デプロイ時間が掛かる
  • オペミス
  • 手動オペレーションの秘伝のタレ化
  • 職人誕生
  • ビジネスとの付き合い

学び

  • 常にビジネスは変化する（それに対応する）
  • どこか妥協するとすぐに大きな負債になる
  • 透明性が大事

ビジネス層とのコミュニケーション

  • 常に議論する
  • 簡単にYESと言わない
  • ビジネス層にも見える化

VS: パイプラインとか後でいいから動くものまず見せて！

  • 次のアップデートとかも手でやるの？
  • バグ修正を緊急でやって、疲れた状態で手動リリースするの？
  • 一度やらないと次もやらないでしょ？
  • 抜け漏れない？

マインドセットの浸透についての組織論

  • 信頼貯金を積み上げて実績を作る（時間がかかる）
  • 思いに共感してくれる仲間を見つけて広げる
  • 技術力を示す
  • 仲間とのコミュニケーションを絶やさず

質疑応答など

Q. CI/CDの必要性から説明しなきゃいけないケースがいまだにあるのが辛い

ベテランのエンジニアの方とかで、手でやればいいじゃん論がいまだに強い

  1. 言い続けること・感染させていくこと

Q. 初心者なので入りやすいところを知りたい

  1. CDは後回しで、linterとか静的解析とかをCIして通知するみたいなところから始めるのが良いかもね
    テストから入るケースが多いはずだから、CIから始めなきゃだめだよね
    パイプラインにはアプリとインフラの赤魔道士みたいな人が必要

Q. プロダクション環境がDockerじゃない場合のCIでの自動テストの環境どうしたらいいか

  1. 多少の環境差異があってもランタイムのバージョン等が揃ってれば基本的には大丈夫なので、やった方が良いは良い
    インフラに依存が大きいものであれば…難しい

Q. パイプライン中にDockerイメージのビルドを入れると遅い

  1. Dockerのイメージビルドが遅い要因は色々ある
    マルチステージビルドを上手に使うとか

レガシーをぶっつぶせ。現場でDDD！に参加して

genbade-ddd.connpass.com

イベントに参加してきました。

かなり後の補欠だったので無理かと思ってましたが、前日に繰り上がって参加できました。

そもそもDDD（ドメイン駆動設計）について現状の自分の状態は、

  • 業務での利用経験なし（DDDでやってます！って言っているプロジェクトはあったが、中身は全然そんなことなかった）
  • 個人のPHP+Laravelプロジェクトで手探りで導入中
  • エヴァンス本未読…

という感じで、初心者もいいとこです。

会場はYahoo!さんのオフィスでした。

併設されていたコワーキングスペースは一般利用もOKとのことなので、機会があれば利用してみたいです。

lodge.yahoo.co.jp

ソフトウェアの核心にある複雑さに立ち向かう

株式会社ギルドワークス 増田 亨

www.slideshare.net

オープニングがあって、最初は国内DDDの第一人者でもある、株式会社ギルドワークスの増田さんのセッションでした。

レガシーなシステムはやり方によっては1, 2年で出来上がってしまうというのが、確かにと思う部分がありました。

完全にイニシャルのスピード重視で作ってもよくないし、きっちりかっちり数年がかりで作っても良くなるわけではないし、変更容易性を意識した設計が重要ということですね。

ドメインロジック ≒ ビジネスルール

ビジネスルール自体はそこまで複雑でない場合もあるが、ビジネスルールを適用する条件分岐が複雑にしていることが多い。

自分も以前ユーザーのロールや認可周りでぐちゃぐちゃになったコードを見たことがあったので、ちょっとわかりみがありました。

DDDはその複雑になりがちなビジネスルールにどう対応し、変化を実現していくかのための方法論というか概念なのかなと考えました。

あと印象的だったのは圧倒的に「型」が重要であるということ。

プリミティブな型ではなく、値の振る舞いを明確に定義した値オブジェクトを型として厳密に扱えるということは、DDDにおいてマストだということでした。

これも非常に納得のいく話で、プリミティブな型や型の曖昧な値が露出してしまった瞬間に、条件分岐が断片化してしまう可能性が出てきてしまいます。

増田さんは基本的にJavaで考えているとおっしゃってましたし、厳密にやるには静的型付けの言語を選択するのが賢い手かもしれません。

自分では主にPHPで書きますが、7系なら比較的型を厳密に扱えるものの、配列表現などではarrayをむやみに露出させないように気を遣うことが多く苦戦します。

Ruby（特にRails）ではこの辺がやりづらかったり、言語によってもDDDに対するアプローチは考えないといけないことが多そうです。

レガシーシステムからモダンな環境への移行 ～Y!プレミアム・バックエンドシステムのリニューアル～

ヤフー株式会社 清水 将貴

続いてはYahoo!の清水さんより、実際にレガシーシステムをモダン化してリニューアルする（している）お話でした。

「どのように（How）」モダン化するのかではなく、「なぜ（Why）」モダン化する必要があるのかを考えるのが重要というのが非常に印象に残っています。

Whyに注意して考えた結果、変化に強いというビジネス目線と、改善しやすいというサービス目線があることに気づき、DDDというアプローチをとったとのこと。

どうしてもレガシーなコードを向き合っていると、モダンでイケてる構成にすること自体が目的になってしまいがちですが、気をつけたいと思いました。

あと全てを詳細に作り込むのではなく、重要なところはしっかり作り込み、そうでないものはざっくりやるのも大事というお話がありました。

重要かそうでないかをしっかり見極めるために、ビジネス要求の大きさ x 運用コストの大きさで考えるというのは合理的で非常に勉強になります。

ベンチャーでドメイン駆動設計をやるとどうなるか？ 〜Pythonで型に倒してみた〜

株式会社チームボックス 安西 剛

続いては具体的な話が聞けそうだったので、安西さんのPythonでDDD実践してみた話を聞きました。

実際に具体的なコードやディレクトリ構成を見せながら説明していただき、非常にわかりやすかったです。

Pythonでも3.5から導入されたType HintsとInteliJのPyCharmを組み合わせれば、型のある世界でDDDできるとのことでした。

とはいえ、特にWeb系で選択肢に上がりやすい動的型付け言語でいうとPHPやRubyもありますが、型という点に注目するとPHPにやや優位性があるのかなと感じました。

あとは開発のフェーズにおいて、0→1、1→10、10→100、100→∞とアプリケーションが大きくなっていくとき、10→…を超えてしまうと大きく設計などを戻せない境界線のようなものがあるというお話が、なんとなくですが共感できました。

10までの間にきちんと変化に強い設計を組んでおきたいところですね。

DeliveryとQualityを両立させるために僕らがやったこと 〜トラベルシステムの技術全面刷新〜

ヤフー株式会社 関口 岳志

www.slideshare.net

続いてもYahoo!さんからで、今度は関口さんによるセッションでした。

現実的に存在する制約の中で、品質の高いものを作りそれを維持し続けていくためにどうするかというお話でした。

特に刺激的だったのは、ビジネスサイドの同意と承認を得るために、改善前後のコードに対して同じ仕様変更を実施し、その工数差分を数値として出して改善を推進するための材料としたところでした。

コードと向き合う人はリファクタリングや再設計の必要性を肌で感じられますが、そうでない人にとってはただのリスクにしか受け取られないこともよくあることで、そのため改善系の工数はなかなか承認が降りないケースは過去にもありました。

関口さんのように具体的な数値で見せるのが最も効果的なのは間違いないのですが、なかなかパワーが要ることなのは間違いないので、尊敬します…。

また、どうしても必要になるのが中心となって設計を進める人と、同等レベルでその人の壁打ち役となる人というお話もありました。

もちろんメンバー全員が精通していればいいですが、一人が中心となって進めざるを得ないケースのほうが多いと思います。

そういったときに壁打ち役の人がいるのといないのとでは、中心になる人の負担が非常に大きく変わってくるので、ある意味中心となる人以上に重要な役どころかもしれません。

ドメイン駆動設計とマイクロサービス

ヤフー株式会社 三石 広樹

次は三石さんによるマイクロサービスを切り口としてDDDの導入に至った経緯を聞きました。

まずマイクロサービスありきで進めてしまった結果、変更に弱いサービスが出来上がってしまった失敗談を踏まえ、DDDと組み合わせることで変更に強いマイクロサービスを作り上げていった具体的な過程が聞けて、とても参考になりました。

技術要件が先行してしまった結果、ビジネスの要件に対応しづらくなるというのはどうしても起こりがちで、開発側からするとなぜうまく回らないのか…とかなり苦しい気持ちになるケースでもあります。

設計を検討する際に、テーブル構成とリレーションを意識してしまうことがよくありますが、そこから一旦離れてモデリングしていくというのはなるほどという感じでした。

言われてみれば自分でもテーブル構成をどうしても先に考えてそれに引っ張られがちだなと思ったので、気をつけていきたいです。

ビジネスルールの複雑さに立ち向かう実践技法

株式会社ギルドワークス 増田 亨

www.slideshare.net

増田さんのお話の後編でした。

ビジネスルールについて、4つの象限から捉える話が非常に興味深かったです。

どうしても小手先というか、具体的なドメインモデルの表現だけに目がいってしまいがちですが、現実世界でのビジネス的な視点や、ドメインモデル全体を俯瞰してみることなど、必要に応じて視点を変えて見ることで解決の糸口になったりするという内容でした。

あとはビジネスロジックを表現するための値オブジェクトの重要性、コレクションの操作を内包して操作処理の断片化を防ぐなど、非常に実践的な内容で勉強になりました。

また、さすがにビジネス視点での話も非常に納得感のある内容で、DDDとは切っても切れないものであることを再認識しました。

ぜひまた別の機会でも増田さんのセッションを聞いてみたいです。

パネルディスカッション&質疑応答

最後に、参加者からの質問に登壇者がパネルディスカッション形式で回答してくれました。

DDDに対する理解が得られないケースや、業務委託の人にどのぐらいお願いするのかなど、以前苦しんだ部分に近い内容もあって非常に自分得な内容でした。

（業務委託の人は切りまくる！とか強烈なご意見もあって、おおう…ってなりました）

あとはユビキタス言語の管理については、どこもあまりうまくいってないですよとか、自分でも以前管理に失敗してメンテできなかったケースがあってやっぱりそうなんだと言う感じでした。

最後に

DDDというやや抽象的なテーマで、なかなか実践的な内容に触れられる機会が少なかったですが、今回のイベントは全てのセッションが非常に実践的で、ためになるものばかりでした。

実際に導入する際のハマりどころや、失敗してしまった事例などが現場の方々の体験談として聞くことができて、今後の参考にできそうでした。

エヴァンス本トライします。

エンジニアリング組織論への招待を読んで

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

読了しました。 現時点で自分が抱えていた様々な疑問や悩みにとても良く刺さる内容で、大きな学びになりました。

何か良くないのはわかるが、言語化できないようなものを言語化してくれているので、今後また悩んだ際にも重宝しそうです。

できればエンジニアだけでなく、むしろマネージャーや経営層の人にこそ読んでもらいたい内容でした。

以下キーワード

今度はTHE TEAMを読みたいなと思っています。

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則 (NewsPicks Book)

PHPerKaigi2019に参加して

今回PHPerKaigiは初参加でしたが、そもそもこの手の技術イベントに完全プライベートでソロ参加した事自体初めてだったので、良い機会と思い感想など残しておきます。

今後またイベントに参加していくぞという気持ちと、普段からアウトプット不足は認識してるので、感じたことだけでも吐き出していくぞという気持ちです。

3/29（金）の 前夜祭は普通にお仕事などしてたので、3/30（土）からの参加でした。

@tomzohさんのオープニングを聞いている頃はまだ「ああ…やっぱり落ち着かないなぁ」など感じてましたが、せめてチケット代のインプットは得て帰らねばという考えでその場におりました。

speakerdeck.com

最初は@Fendo181さんの「フレームワークを作りながらLaravelのアーキテクチャを学ぶ」を拝聴しました。

登壇当時社会人三年目とまだお若いのにすごい！と思うと同時に、ご自身の会社名をしっかり出して登壇している姿を見て、こういう活動にとても理解がある会社なんだなと感じました。

※ そもそもGMOペパボさんはPHPerKaigi2019スポンサーでしたしね。

FWを自作してLaravelと比較しながらDIやコンテナの説明などしてくれていましたが、LaravelもDIもコンテナも触れておいて良かったです。

特にLaravelでテストを書く際に、DIやコンテナのありがたみを感じていたところだったのでわかりみが深かったです。

speakerdeck.com

次は@hidenorigotoさんで「抽象化って何？」でした。

これはいつもコーディングやレビューしながら自問自答していたところだったので、とても楽しみにしてました。

現実世界での例とともに抽象のハシゴを登っていく話と、抽象化は視点によって方向性が変わるという話のおかげで、自分の中で抽象化への理解が数歩深まった感触を得ることができました。

※ このあたりでTwitterに投稿する余裕が出てきたようです。

続いてランチ＆ランチセッション…正直ランチは外に出ようか迷っていました。

一人だし、お弁当もらって一人で食べてたら浮かないかな？とか、普段の弱々しい気持ちがまたポツポツと出てきてました。

でも朝よくわからずランチチケットもらっちゃったし、参加したかったのにチケットもらえてない人もいるのに参加しないなんてよくない！と思い、お弁当いただいてランチセッション聞くことにしました。

speakerdeck.com

ランチセッションはランチスポンサーのオウケイウェイブさんから、@blue_goheimochiさんによる「Take Off The Colored Glasses」でした。

テクニカルなセッションではなく、オウケイウェイブという会社の紹介や、フィロソフィ的なものの紹介がメインでした。

※ 皆さんご飯食べながら聞く形になるので、そういう内容の方がたぶんお互い良いですよね。

各々の色眼鏡を外して、同じ色眼鏡をかけ直すと、文字にすると矛盾を感じますが、とても共感できる内容でした。

ブルーマンデー対策のお話は、初めて聞きましたがなるほどなと。素直にとても良いなと。

うだうだ悩んでましたが、ランチ参加して良かったです。

オウケイウェイブさん、@blue_goheimochiさん本当にありがとうございました。（ごちそうさまでした）

speakerdeck.com

午後イチは@yoku0825さんで「MySQLにWEBアプリのログを保存しているケースの8割くらいが幸せになる方法」でした。

直近ではMySQLにログ入れてないなと思いましたが、以前の職場では場合によっては入れていたなとか、InnoDBの圧縮を使っていたことを思い出してなんだかエモい気持ちになってました。

当時よくわからないなりに調べて、適切なページサイズとか検証してました。

さらに新卒時代にMyISAMでFULLTEXTINDEXで全文検索などやっていたことも思い出し、なんだか最近ちゃんとDBと向き合ってないのかな？なんて気持ちにもなっていました。

あと発表の流れが、なんというか引き込まれる感じで、エンターテインメント性があるなあと感じながら聞いていました。

speakerdeck.com

次に聞いたのは@77webさんで「設計力を上げるバリエーションの見極め術」でした。

バリエーションの変化はビジネスの変化という捉え方が、なんだかとても前向きで良いなと思い、普段「この仕様変更は誰得なんじゃい…」などと感じてしまいがちな業務でも、捉え方を変えてみようかなと思えました。

条件分岐禁止ギプスなど面白い取り組みもやられていて、課題解決に楽しんで向き合っているように感じられてとてもナイスでした。

speakerdeck.com

続いては@hypermktさんで「モバイルアプリ向けAPI開発を通じて学んだこと」を聞きました。

技術選定って何を基準に選定するの？や、API設計についてサーバーエンジニアだけでなくアプリエンジニアも一緒に「Web API The Good Parts」を読みながら学んだことなどを聞き、とても健全なお気持ちの環境なんだなと素直に素晴らしいと感じました。

Laravelがドキュメントに書いてないけどこっそり機能提供してたりするのはちょっとわかりみあるなと思い、そこがまたLaravelのFWのコードを読む楽しみでもあるんだよななどと思いながら聞いていました。

speakerdeck.com

次は@koriymさんで「RESTの力」を拝聴しました。

ちょうど最近業務でもRESTを意識しながらAPI設計していた部分があり、どのぐらい自分の中のRESTの認識が正しいのか答え合わせ的なイメージで臨んだのですが…。

自分が「イケてるかも！」などと思いながら作っていたAPIたちは、なんというか数字が書けるようになっただけで「数学完全に理解した！」と言っているぐらいにちっぽけなものだったということを思い知らされました。

HypertextとInternetからWWWが生まれ、その後RESTという考え方が生まれ、APIのバージョン管理がどうとかURIがどうとか単数形複数形がどうとかはよく議論されるが本質的ではないんだとか…。

そして最後の締めくくりと、発表後のあの空間に漂っていたなんとも言えない雰囲気は、なんだか映画の名作を観終わったときのような気持ちの良さがありました。

今回あの力強い引き込まれるようなセッションが聞けて、本当に良かったです。

もっともっとRESTは考えながら付き合っていこうと思いました。

speakerdeck.com

その次は@ippey_sさんで「サーバーレスPHP」でした。

サーバーレスは業務でもプライベートでも触れた経験がなく、仕事で聞いたAWSやGCPのセッションで紹介されていたぐらいの知識しかない状態でした。

しかしセッションは非常にわかりやすく、PHPerフレンドリーで、これなら自分にもできそうかも！やってみたい！と思える内容でした。

続いて@niisantokyoさんの「Swooleでフレームワークを高速化 - もう動作が遅いなんて言わせない！」を聞きました。

ちょうどlaravel-swooleが爆速ですごいというのを聞いたところだったので、タイムリーに興味津々でした。

結果としては早いのは間違いないけど、そもそも普通のWebアプリとは全然別物になるということで、具体例も合わせて紹介していただけてとても参考になりました。

speakerdeck.com

一日目最後は@hanhan1978さんの「PHPerのための計算量入門」でした。

いわゆるOrder記法だったりとか、基本に立ち返りつつも、「必ずしもin_arrayが悪でarray_key_existsが大正義ってわけではない」というお言葉もちゃんといただけて、この辺の使い分けがしっかりできるPHPerでいたいし、周りもそうであってほしいと改めて思いました。

そして@tomzohさんのクロージング「Today's update」を聞き一日目は終了しました。

※ PHPer茶会に参加する勇気は出ませんでした…。

自分でもわからないうちにテンションが上がっており、なかなか寝付けずにTwitterでPHPer茶会の様子の監視や自分でまとめていたメモを見返したりして、夜更かししていました。

二日目は寝坊しました。オープニングには間に合わないし、最初のセッションも完全に間に合いません。

たぶんいつもの自分だったら、「昨日一日参加しただけでも十分頑張ったし、家のことも片付けないといけないから今日はいいか」となるところでしたが、ここで変わらないとこの先ずっと自分に言い訳して妥協していくことになる！と思い、やっとの思いで起き上がりました。

結果的には起き上がってよかったです。素直に今朝の自分を褒めてあげたい。

speakerdeck.com

そして二日目最初は@cotolier_risaさんの「PHPerKaigi2019のサイトができるまで」から始まりました。

基本的にはWebアプリケーションの開発しかやってこなかった身で、Webデザインの話をちゃんと聞いたのはもしかしたら初めてだったかもしれません。

コンセプトアートやロゴのお話ももちろんそうですが、アートディレクターのお仕事や、デザイナーさんとかもGitHub使ってるんだということや、バイト君が来なくても困らないコンポーネントの分け方などなど、新鮮でとても学びがありました。

デザイナーさんがそのデザインに込めた思いとかを聞くと、エンジニアとしてはなんとか実現したい！と思うし、そういう思いが生まれる環境に身を置きたいなと、しみじみ思いました。

speakerdeck.com

続いては@ex_takezawaさんで、「Hack HTTP Request and Response Interfaces」を聞きました。

すごい難しそうだ…という思いと、界隈にあまり詳しくない自分でも名前を聞いたことあるぐらいだから、ytakeさんってすごい人なんだろうな…という思いから、ややびびっておりました。

しかしセッションではPSR-7の話などが出てきて、ちょうどGuzzleでrequestAsyncやらPromiseやらジェネレータに四苦八苦していた自分には意外とすんなり入ってくる部分もあり、結果的にはこれ以上ないタイミングで聞けたような気がします。

※ やっぱり難易度が高かったのはその通りですが…。

また、ytakeさんはアイスタイルのCTOですし、他には@hidenorigotoさんもmercariのマネージャーオブマネージャーだったり、委員長の@tomzohさんもCTOだし、他にも役職付きの方々がばんばん登壇されていて、それってしっかり技術のある人がエンジニアを引っ張っていってるってことだと思いましたし、そういう環境でエンジニアがやれるってとても素晴らしいことだなと感じました…。

speakerdeck.com

ランチは寝坊したので当然チケットもらえておらず、おとなしく練馬近辺でランチを取り、スタバでTwitterを監視したり午後に向けて気を高めていました。

RESTの力の残滓が残っていたのを観測しました。

speakerdeck.com

午後は@soudai1025さんによる「アンチパターンから学ぶ、RDBの正しい設計」から始まりました。

こちらの@soudai1025さんも元々認識していた数少ない人のうちの一人であり、毎度のごとくびびりながら向かいましたが、結果としてはとてもわかりみのあるセッションでした。

紹介されていたアンチパターンもだいたい触れてきていたことや、ORMやキャッシュやロックの話も「うんうん」となる部分が多く、RDBMS周りは意外と修羅場をくぐっていたのかもなとちょっと自信がつきました。

※ でも本は読んでなかったのでちゃんと買います。

slide.seike460.com

続いては@seike460さんによる「PHP監視、サービスを守る為に行う不測の事態への努力」でした。

監視については弱い部分である自覚はあったので、ちょっと身構えておりました。

しかし、開発視点ではなくユーザー視点で監視するべきものを考えるという話を聞いて、一気にイメージが鮮明になった気がしました。

死活監視、ステータス監視、レイテンシと、それぞれ何のために見るのかと考えると、ストンと腹落ちしました。

実際にオオカミ少年化した監視のアラートが鬱陶しいなと思うことは何度もあったので、インフラエンジニアとの歩み寄りが大事だなと思いました。

ここからは怒涛のLTタイムで、バンバン流れるようにLTがデプロイされていきました。

speakerdeck.com

www.slideshare.net

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

ルーキー枠なる登壇初心者枠の方々の発表があったのですが、これでルーキー？と思うほど皆さん素晴らしい発表で、完全に圧倒されてしまいました…。

その後、徳丸先生こと@ockeghemさんによる「PHPerチャレンジ 「徳丸 浩の挑戦状」解説」がデモ付きで行われました。

基本的なものから巷で話題のものまで、色々な脆弱性や危険な仕組みを悪用したデモは非常にためになったし、直前のLTのネタを拾って自分の発表に還元するなんてテクニックは、やっぱり場馴れ感が違うなと脱帽しました。

そして最後は再び@tomzohさんによるクロージング及び、PHPerチャレンジの結果発表や各表彰などが行われました。

一位が同点で、正誤に関わらず最後にコミットしたほうが一位になるなんていうなんともライブ感のある結果が見れたり、とても盛り上がっていました。

そうこうしているうちにクロージングも終わり、皆さんは懇親会へ足を運び、私はスタバに寄ってから帰りました。

以上が私のPHPerKaigi2019の参加記録です。

全て書いたら思いの外長文になりましたが、参加して本当に良かったと思いました。

今後もなるべく足を運ぼうと思いましたし、登壇されていた方々の情報発信は追いかけようと思いましたし、もっと自分と周りの技術に目を向けていこうと改めて思いました。

聞く側で参加したぐらいでいきなり何かが極端に変わるわけではないと思いますが、今回の参加をきっかけに自分のバリューを高めていけるよう、頑張ろうと思いました。

最後になりましたが、PHPerKaigi2019とそれに関わった全ての方に感謝します。

phperkaigi.jp

ここまで読んでいただいた方、小学生並みの感想文で大変失礼しました。