やったこと・書いたもの{2020,02}

先月は、これを付け始めてから初めて「何もなかった1ヵ月」になってしまったのが何だか今の自分の状況を物語っているようで象徴的なものを感じる・・・

OSS

Release Fix unhandling event · Connehito/cake-sentry · GitHub
ずっと出せていなかったやつ・・・いろいろな問題が絡んでいて、それらをすべて取っ払う必要があったので、触る->予想してないところでつまずく -> 詰まる -> テンション下がる・・ -> 時間が経ってから再開、みたいなサイクルになってしまい変に時間がかかった!!

Release Support for CakePHP4 · Connehito/cakephp-master-replica · GitHub
こっちも「だそうだそうと思って遅れてたやつ」、cake4対応のPRもらってから丁度1ヵ月が経過・・・

勉強会・LT

=> 登壇後のエントリー #phperkaigi に参加してきました (day1) - 大好き!にちようび

その他

#phperkaigi に参加してきました (day1+day2)

「登壇しました」な話は昨日書きました

daisuki.nichiyoubi.land

ので、色々な感想などは終了後に書きますので の部分です。
公開用に資料も整えています現在。


全体的な感想とか

多くの人が既に語られていますが、とても「参加者同士の交流が多い」イベントだったなぁ〜と思います。

楽しませていただきました!
去年が勿体ない感すごかったので、day-0/中日の懇親会(茶会)/終了後2次会(post party)にこそ参加しなかったものの、day-1/2のオープニング〜クロージングまで参加したのは、ある種のリベンジに成功したような面もあります。
(ここ暫くのテンションが安定してこなかったので、最後の懇親会以外はパスした形。結果論、自分の発表終わってからは気楽に過ごせていたし、post partyは参加しても良かったかもなー)

自分は割とトークを聴いていた数が多かった(と思う)ので、IRTやアンカンファレンスには参加しそびれていました。
今度どこかで似たような企画があったら参加してみたいな。
セッションや発表から学ぶことや得るものも多いのですが、「より具体的で生々しい話・深い話」というのは、双方向のコミュニケーションの方が強いなぁとはやはり感じるのです。もちろん、プロポーザルを出して前に立って話す人の知識や経験は実があり興味深いものなのですが、やはり「レベルをどうするか」「前提をどう共有するか」が本当に難しいので。その辺りのチューニングは、どうしても「公約数」に寄せる必要がでてしまう。・・・ということで、「自分と相手」の中で議論できると、効果は高いよねと。

懇親会

ビール美味しかったご飯美味しかった、これ無料で(※スピーカー)参加させてもらえるの恐縮ですらある・・・
ハンバーガー食べたかった。そこだけ失敗した!!という点。

ノベルティが凄いな〜と思う

前回のパーカーも良い感じで嬉しかったのですが!今回はトートバッグが「こだわってるな〜」と思いました!!あとロゴかわいい。

あとモバイルバッテリー(by CameWith)とアイスクリームスプーン(by Digital Circus)すごい!嬉しい! アイスクリームスプーン使ったこと無いので、あとでスーパーカップ超バニラ買ってきます。

色んな人と話せてよかった

前職の人だったり、(もちろん今の会社の人もいましたし)、あと12月のPHP Conferenceで面識を持った人とまたお話できたり〜で。
数あるコミュニケーション促進施策やサブコンテンツの中で、最も異様なのは「トレーディングカード」だったのではないかーと思います。自分からはそこまで積極的に使ってなかったに関わらず、数えてみたら30枚ほど交換してたみたいです、ビビる・・・・

普段の勉強会とかで名刺をこんなに持って帰ってきた事が個人的にはないので*1、面白いなぁと改めて思います。 (初対面じゃない相手にも使えるので、その分の枚数は増えてる〜という事情もありそうですが!)

地味ですけどネームタグがデカい・視認性が高いのはホスピタリティ高いなって思っていて、「SPEAKER」って書かれた札をぶら下げて歩いているとそれだけで発見してもらったり声かけてもらったり〜が発生するので嬉しい。し、「あ、このアイコン見たことある人だ!!」がナチュラルに発生するので、助けられました。 ありがたや〜
自分に限ったことじゃないと思っているのですが、わざわざプロポーザル出して前に出て話している!という人は、要するに「そのトピックが好き」「その話をしたい」人だと思うので、自分が話したネタに対して感想貰ったり質問や意見貰ったり〜っていうのは嬉しい瞬間だなぁという。

他にも、一方的にTwitterで知っている人だな〜と思っていた方から「cakeの情報とか発信してますよね」と言われたのメッチャ嬉しかった!(今回のトークも「CakePHP」ってタイトルに入れてたし、 #PHPerKaigi タグのツイートでもいくつか投げてたから、このイベントの中で認知を得たって可能性もあるけど)

LT

前回はLT参加で、この規模で喋るの初めて(高校の時に全校の前で喋ったことはある・・・)だったような気もするのだけど、その時に「凄くやりやすいなぁ」と感じた思い出。長谷川さんのMCと、それに呼応して会場の空気も暖かいのが本当に大きい。

それは今回も健在だったなぁーと思います。「初めて登壇するならPHPerKaigiが良い」というのは、個人的にも思う所*2

そして例によって、初めて発表する〜〜とは思えない上手な人や練られた内容が多いな、と思いました 💨
day1がルーキーズLT、day2が(ルーキーズでない)LTということで、「これday1大丈夫なのかな」とか思ったけど、全く「普通のLT」と遜色ない感じになっていたなーという感想

教えてもらったものや興味深かったもの

今回のイベントの中で「お、ソースコード見てみたいな!!」という、具体的な気になりを持って帰れたのでホクホクしております。 やはり「コードから得る学び」というのはデケェので・・・!

koriymさんから教えていただいたもの

このイベント全体を通して、郡山さんとお話を出来たのは最も良かったことの内の1つだなぁ。
自分の発表の後の質疑応答でフィードバックというか「こういうのもあるよ!」というのをご紹介いただき、「CakePHP3とDIをつなぎ込んでいる例」があることを知りました。

それがpiping-bag。

github.com

発表の中で「CakePHP4.1でコンテナ来るはず」というのに言及した事がキッカケで頂いた声ですね。
Cake自体は「PSR-11: Container interface を採用する」という方針になるのかと思うので、どうなるんだろうな。この記事とか参考にしてみよう。もしくはphpleague/containerになるのかな。

何にせよ、CakePHP/Ray.DIのコアメンバー・作者同士のコミュニケーションを取りながら書かれている〜ということで、参考になるものが多そう。また、「ライブラリ自体はCakePHP本体的には別のものを採用する」となったとしても、「CakePHPの中にDIをどう協調させるか」みたいな部分でのアイディアが組み込まれていると思うので、その点を見たい。

というかネーミングがお洒落すぎでは🍵

で、もう1つ教えてもらったのが、郡山さんが「お礼みたいなものも兼ねて」作ってみたというコチラ。

github.com 先のものとは逆に、「CakePHPのORMを使ってみた」例。
まっとうにDIを使ったことが無いから習作欲しいな〜と思っていた矢先なので、かつ「CakeのORMなら分かるわ!」というのがあるので、コレ参考にして何か作ってみようかなーという気持ち。

wakabadouさん

【PHPerKaigi2020】ぼくのかんがえたさいつよQueryBuilder - Speaker Deckで扱われていた題材。

github.com

だいぶ強そうなタイトル・・・と思いながら発表を聞いていたら、しっかりとコンセプトを持って、チャレンジングに開発をしているんだなぁと感じました。
「堅牢性」「再利用性」みたいなところにこだわっている印象を受けたので、中身みてみたいな〜と思っている次第

zonuexeさん

「めちゃくちゃ作り込んで完成させるぞ!」みたいな時間は恐らくなかったんじゃなかろうか・・とは推察しつつも、自分の観測範囲にいる「強い」phperのコードが見られるの貴重だな、という。そしたら見たくなりますよね!!

github.com

発表をきいたものや感想など

たくさん聞かせて貰った中で、とりわけ印象に残ったものを。
ただ、個人的には「10分や20分の時間の中で、なにか1つ印象に残る言葉があったら成功なのではないかなぁ・・」という気持ちもあるので、発表中で「残ったフレーズ」を中心に振り返る次第

(順不同です!

実際に聴けなかったけど資料を後から拝見したシリーズ

  • Deep Module in PHP - Speaker Deck
    • いとしょさん まえの かいしゃで おせわに なったり いっしょに しごとを した ひと です
    • 今ありとあらゆる方法で「良いコードを描き出す言葉がほしい、説得力が欲しい」と感じる日々なので、「A Philosophy Of Software Design」読んでみたいな!!と思った次第
  • もっと気軽にOSSに Pull Requestを出そう!/ Let's make a PR to OSS more easily - Speaker Deck
    • コレはもうタイトルが全て!!て感じだけど、PR投げるの「実は難しくない」って思うから、こういう資料がインターネットに出回るのメッチャ良くないですか・・・
    • 実際、自分の「IDEが警告してきてphpdocが変なのに気づいてパッチ投げる」みたいなの多い
    • あと前職だと「これ直せるのでPR投げてみませんか〜〜」って同僚たちをけしかけたりしてたのだけど、要するに「きっかけがあるかないか」「目の前のそれをキッカケと思って飛びつけるか」の差なのかな?と思う
  • レンサバけもの道 - Speaker Deck
    • (早く動画で見たい・・・!w
    • 眺めてたら自分の発表のスライドが引用(?)されててびっくりしたw
  • https://speakerdeck.com/hiro_y/about-php-annotations
    • こっちでは12月に書いた会社のブログが言及されてるワーイ
    • CakePHPのFixtureManagerでアノテーションを使った機能強化をやってみてぇなあ!と思い描いてた時期があるのを思い出す
    • やっぱりDoctrin/annotationsを使うのが気楽なのかなー

実際に聞いて印象に残ったフレーズがあったよシリーズ

  • PHPerがこれから「型」とお付き合いしていくために - Speaker Deck
    • 「PHP7の型宣言はパフォーマンス的にマイナスになることはない(むしろ性能が上がる)」というのは、自分の中で勘違いしていた部分だったので知れてよかった
    • 動的型付け言語・静的型付け言語の比較がとてもわかり易かったし説得力があった
    • 「(PHPは)必要に応じて柔軟さを取り戻すことも出来る」
  • 知らないWebアプリケーションの開発に途中からJOINしたとき、どこから切り込むか? / PHPerKaigi 2020 - Speaker Deck
    • 話の筋道が分かりやすくて、さすがだな〜〜という気持ちに
    • 自分が今まさに(って言ってて良い期間でもないんだけど本来)「途中から入ったサービス」に居る中で、「どうやって自身の力を100%出せるところまで持っていくか」に普請する日々。
    • 「なぜ開発に取りかかれないのか」をレイヤー化して整理してるの分かりやすかった。そのうえで、「自分が得意な所」からアプローチして切り崩していく〜というのも1つのヒントというか大事なポイントとしてあるのかな、とは個人的に思ったところ
      • 自分の場合は「PHP/CakePHP/Docker」辺りは、切込みに使える武器になってる実感がある
    • 「(途中参加したPJへのキャッチアップにはオーバーヘッドが生じる」という話で)オーバーヘッドというと・・・エンジニアリングで解決できそうじゃないですか」
  • RFCの歩き方/How to read PHP RFC - Speaker Deck
    • LT。気になってたやつ
    • コレはもっと早く知れたら嬉しかった系かも知れないw 最後のスライドに全てが詰まってるかもな
  • もしもPHPソースコードが読めたなら (#PHPerKaigi 2020イベントレポート - Innovator Japan Engineers’ Blog)
    • 最近ずっと「あ〜〜PHPソースコードが読めたならなぁ!」と思っていたのでドンピシャなんですよね。ってことでタイトル見てから気になってたやつ
    • 「取っ掛かりはどんな感じが良いのか」を示してもらえたので有り難い。よーし!
  • 35. クリーンアーキテクチャと DDD(nrslib) | PHPの現場
    • 公開早いな・・・・!
    • 「転がってきたボールは全部あなたのものです」「なんでもかんでもやってると色んな事ができる」

終わり

トータルで見て、とても「カラーの濃い」イベントだな〜と思います!
3回目なのに変化していって攻めてるの凄いな〜とも。

また来年も開催されることを祈りつつ!!

*1:ツールとしては使いたいけど,「会社」な意識を持ち込むのが嫌でして

*2:参加者の方の、この辺りのトピックに絞った記事も: https://tsukahara-lbk.hatenablog.com/entry/2020/02/12/152435

#phperkaigi に参加してきました (day1)

https://phperkaigi.jp/2020/ に行ってまいりまして。
プロポーザル出したら採択していただけたので、自分も30分枠で喋ってきました。

f:id:o0h:20200211135249p:plain

前夜祭(day-0)については参加を見送って、登壇準備等に費やしておりました・・
そのおかげもあって「発表用」と「公開用」の2タイプを用意できそうな兆しがあるので、ちょっと遅らせてupさせてください。
その代わりに・・・って事でもないですが、主旨をテキストに起こしてまとめてみます。
(簡単にまとめます、って言おうとしたけど30分枠の話なのでそこそこの分量になりました😇)

色々な感想などは終了後に書きますので(iwillblog)、この記事は「発表した内容の掻い摘み」と「Twitterで拾った感想・声に絡んで見る」というものです。 会場にてバタバタと書いているので、見直しとかは後ほどやりますが、ご感想・ご質問・ツッコミなどあったら呟いていただけると!

発表内容の掻い摘み

  • Pt.1 「レガシー」「モダン」とは?
    • このトークでは「改修・保守」といった「進化させる」のが難しいモノを「レガシー」と呼びたい
    • 「ソフトウエアは使われ続ける限り進化していく」もの(リーマンの法則より)
    • 「レガシー」の逆サイドに「モダン」があるなら
      「腐った(腐りかけの)コード」に対応するのは「防腐剤」とでも言えそうに思う
    • 肝要なのは「新しい機能を取り入れたもの」ではなく、「未来に向かってついていけるもの」という点。
      これが「モダンであるか」という問いなのではないか
  • Pt.2 PHPの進化
    • 言語としてのPHPや、コミュニティ(PHPで書かれたソフトウェア等)の進化を振り返ってみる
      • 〜2008年 / 〜PHP5.2
      • 〜2014年 / 〜PHP5.6
        • 名前空間の導入とComposerの登場
        • PHP-FIGもこの時期。「FW間の相互運用性」
        • 「複数モジュールを手軽に扱いたい」雰囲気?
      • 2015年〜 / PHP7.0+
        • 型宣言・Expectation( assertが「文」に) の導入
          • ※「タイプヒンティング」が「型宣言」と呼ばれるようになったのは7.0から。
            以後、スカラー値、iterable、nullable、void、objectなど「使える型」が増強されていっている
        • 静的解析ツールの盛り上がり
        • PHPでも固く書きたい」雰囲気?
    • あらゆるものは「因果」があり、「ダイナミズム」が根底にある。
      色々な変化を微分して、「大きな流れ」を読み解きながら「モダンさ」を考えて見るとよいのでは
  • Pt.3 CakePHPを例にとって「進化」を見てみる
    • 主に3点。
      1. 使い手に対して親切にすることで、「レガシー」を排除していける状態を保つ
      2. コミュニティの資産を活用する
      3. コードの品質を保ちやすくする
    • ソフトウェアの進化にとってはフィードバックがあることが重要で、OSSでは「コミュニティ」の力が欠かせない
      • しかしCakePHPは「2.x->3.0」への変更が大きく、ユーザーが「断絶」してしまった
      • この時の経験から、「4.0へはユーザーにとって優しく変化を促す」ことを重要視し始めた
      • CakePHP3は、「3.6からは機能の追加ではなく、4.0へ向けた準備にフォーカスする」という流れを作った
        (最終的に3.8まで進展し、4.0がGAになった)
        • 具体的には @deprecated の付与や E_USER_DEPRECATEDの活用。
          丁寧に「廃止予定」を分かりやすくしつつ現行ユーザーには影響のない形で、進化を促した
        • 「親切さ」と「コードのリストラ」が共存している
      • 移行ツールの提供
        • 過去にも同様の独自ツールを提供していたが、Rectorベースになった
        • これにより、「Rectorを使えれば誰でも使える・コードもフィードバックできる」という状況を生み出せた。「とっつきやすさ」と「フィードバック可能性」の拡大
    • コミュニティの資産に乗っかることは「オリジナルのソフトウェア」であることのリスクを減らすし、流動性も高める
      • CakePHP4は、PSRへの準拠を進めている
        • オートロード(1+4)、コーディング規約(12)、HTTPメッセージ(5)/ミドルウェア(15)、ロギング(3)、キャッシュ(16)。またコンテナインターフェイス(11)にも次期対応予定
        • FW内のパーツが交換可能になるし、読みやすくなる
      • CakePHP自体がFIGメンバーでもあるので、今後も積極的に使っていきそうな気はする
      • Rectorの採用も「似た効果」があるように見えるのは、先述の通り
    • 静的解析やチェックの強化を進めている
      • declare(strict_types=1)の全面適用
      • 引数・戻り値の型宣言の必須化
        • これは3xと違いPHP7以下を切ったから出来たことでもある
      • PHPStan / Psalmの適用
        • 元々PHPStanは利用されていたが、適用レベルが大幅に引き上げられた
      • これにより、(FWの)開発者にとっては「不正確なコードを書いてしまう」という蓋然性が排除されやすくなる。他方で、利用者にとっては「(取り分け型宣言により)IDE等の利用時の開発体験が向上する」という恩恵がある
  • まとめ
    • 「何のためにモダンが良いの」?
      • 未来に近い場所にいるため!
      • 時代に取り残されるのが「レガシー」
    • 「どうモダンさを獲得するか」に対して、PHPやコミュニティの大きなトレンドに則って「モダンさ」を考えるのは1つのヒントになるはず
    • CakePHP4はたんまり”今っぽさ”を実践しているよ!!!
    • 「進化を止めない」ための仕掛け方、という観点で社内プロダクトなどにも参考になるポイントがあるはず

ツイートへのリアクション

このイベントには前回も参加させていただいて、発表内容に対してフィードバックを送れるオンラインシステムを提供してくれているのは大好きな点の1つです。5分間のLTでしたが、色々な声をもらって嬉しいものでした。
それともう1つ、「この時間帯のツイートを見る」が出来ることですね!(冒頭のキャプチャを参照!!)

折角ご感想をいただいているので、リアクションしてみたいと思います。

当初は「CakePHPの設計がどうなったか」みたいな話をしようと思っていたのですが、内容を詰め始めたら「そこら辺は一切触れる余裕無さそうだな・・」となりました🙇‍♂️
今おそらく「クリーンに作ること」のもたらす価値〜みたいなのが再発見されてきつつあるのかな?という雰囲気は感じていて、その観点に対して「CakePHPのような、縛りの強いフレームワークはどうなのか」というのは、トピックになるのかなぁと思っています。
トーク中で「コードの寿命」というのを強調していたので、例えば「FWの死によってアプリケーションが身動き取れなくなう」というのはリスクとして挙げられそうです。に対して、(実現できれば)クリーンアーキテクチャは処方箋になりそうかも・・・・?

と思うのですが、「寿命」というのは、「手前」にも伸ばせる事ができると思っていて、「悩みを少なくして、オーバーヘッドも少なくして」作り始める・動かし始めるというのは強烈な価値だと思います。 ので、「レールを敷く」ようなフレームワークは好物です。
CakePHPは、3.x/4.xになっても「道を示してくれる」力を保ちながら、「パーツを交換することはしやすくなった」状態だと思っています。ふわっとした言い方・・・
一応、CakePHP3をガッツリ使っていたのは前職時代になりますが、その当時は「CakePHPが足かせになっている」と感じたことはなかったです。

これもめちゃくちゃ大事な視点だよな!!と思いました。
そのためにも「(言語やFWの)セキュリティアップデートを迅速に行える状態を保つ」のも必要そうかもな、と感じました。
(何かポジショントーク的な話の展開の仕方になったぞ)
パッチとか新しいの出たらガンガン適用していこうぜ!そのために普段から備えておこうぜ!!となると、テストコードやCI/CD環境の充実も重要になってきそう。ココらへんもまた、「未来に近い場所に居続ける」努力なのかもなぁと思った次第です

コード写してた時間は短かったはずなんですが、このツイート見てビビってましたw
レガシーとかそういう次元じゃない・・・😇
資料公開時には直します!!

そうなんですよ、これは最低限かつ最重要なポイントですよね!!
「なんとなくカッコ良さそう」が「モダン」じゃねーぞ、と思います。

例えばPHP話でいうと、7.0から入った null合体演算子は便利で「使えそう」な場面も多いのですが、乱用しすぎるとリスクになりそうです。 「定義したつもりの変数(やプロパティ)」をウッカリ混入してしまうことになります。
ので、「既存コードを、新しいやり方で、短く書き換えられそう」な時でも、「手段と目的を履き違えるな」というのは言い続ける必要がありそう。

資料作成中に調べていて、「もう10年前!」と個人的に驚いたので言及した話。
今でも読むに値する話が詰まった、素晴らしい本だと思っています。そのため自分としては「今でもおすすめしたい」のですが、確かに「書き方が古い」部分もあるだろうな、って思うと悩ましい・・・
PHPの「中級者になるための」みたいな入門書、決定版がほしい。

これも凄い有り難い指摘だなぁ〜と思っています!!
触れていなかったのは、発表枠の時間的な問題と、自分の見識の浅さの両面からです。

例えば,PHPのyieldはPythonのジェネレータに影響を受けていますし(PHP: rfc:generatorsのFurther resources等を見ると面白いです)、「CakePHPRuby on Railsの」「Composerはnpmの」影響を受けている〜〜っていうのが、何よりの証左な気がします。ちょっと毛色は違いますが「PHP7はHackの」とか。

ということで、他言語や他文化圏も含めて流れを感じ取れたら、武器な気がします。とりわけPHPは、キャラクター的に他言語の影響を受けやすい印象があるんですが、どうなんですかねー

※あとで展開する資料には参考文献をのせます

元lead developerであるMark Storyさんの発表から引用したものです。
CakePHP - The Road Ahead

ここで「CakePHP3の時どうだったのか」が語られているので、ご興味がありましたら読んでみていただけると。

去年のCakeFest(※CakePHP4の正式リリース直前)でのMark Storyさんの発表において、「4.xに移行するにはどうすればいいですか?」という説明の中で使われたスライドがコレですからねw

f:id:o0h:20200211141101p:plain

実際どのくらいdeprecated付けられたんだろう。後で数えてみよう

Safer, More Helpful CakePHP

※ 今回の僕のトークに興味を持ってくれた方には面白がってもらえると思うのでオススメです!

具体例でいうと、「setter/getterの分離」みたいなのが実施されました。
( $a>value($v) をdeprecatedにして、 $a->getValue()$a->setValue()を提供)
これは「コードの可読性を上げる(for human, for 静的解析)」ためのイシューといえますが、急に破棄されたらアプリケーションが死滅しかねないなぁというAPIなので、廃止予告を出してもらえて助かりました。CHANGELOGや移行ガイドを見ると、3.6~3.8時代にかけて、様々な箇所で「setter/getter分離」ポリシーを拡大適用していった様子が感じ取れるかと思います。

ちなみに、地味に私もPR送ったりしてます ✨
CakePHP Add Fixture importing name style rector(for 3.7) by o0h · Pull Request #1252 · rectorphp/rector · GitHub

余談ですが、当然ながらRectorの作者があらゆるFWを使い倒してる可能性は低いので、これOSSコントリビュートデビューのチャンスが転がってる気がします!!!
Cf: もっと気軽にOSSに Pull Requestを出そう!/ Let’s make a PR to OSS more easily - Speaker Deck

ここ、ニュアンス結構ムズいんですけどね。
トーク後に呟いてた補足的な私見です。

個人的にはFIGの活動素晴らしいし、流行って欲しいし応援したいんですけど。
で、「強い人達が集まって良いものを作ってくれる」というところで、自分でオラオラするよりは信頼できるヒントがある・・という事で参考にしています。
他方で、↓でも触れたことがありますが、「必ずしもどうなん」みたいな話もある〜というのも理解できます。

daisuki.nichiyoubi.land

そんな感じなので、 「PSRが標準で、絶対だ!」ということはないぞ というのは、周りに勘違いしている人がいたら教えてあげてください・・・という気持ち。
(この記事のURLを共有するだけで良さそう PSRの誤解 - Qiita


ということで、「取り急ぎお返事」みたいなやつでした! 「反応してもらってるし自分の意見を返してぇ〜〜」って思いつつ、でも引用ツイートとかしたくねーな、って思いからこのタイミングでブログを書いてみたフシがあります。

では、引き続き PHPerKaigiです・・・!

おまけ的に宣伝

気が向いた時に「Cake縛りブログ」みたいのをやっていますので、何か「気になる!」とか「他の人どうしてるのか知りてぇ」みたいな話があったら、適当にIssueを立ててみてもらえると喜びます!必ずしも、全て拾えたりはしないと思いますが、自分の知識のアップデートしつつ・・

PHPカンファレンスに行ってきました & 登壇しました #phpcon

12.01のPHPカンファレンスに参加してきました。
何だかんだ?東京でPHPカンファレンスに行くのは初めてでしたが、でけぇ・・・・・!という感想。
「日本だと最大級のプログラミング系イベント」とは聞いていたものの、いざ行ってみると、変な感想ですが「本当にPHP周辺でこんなに人が集まっとる!すごい!!」という。PHP好きな身としては良い光景でした✨

そんな感じで、なんだかんだで「オフラインイベントの醍醐味は"人"なのかなー」などと思っていた矢先に、「学生時代の付き合いの人」「前前職(新卒時)に働いていた会社のつながりの人」「前職の人」「インターネット上で認知していて、会話はしたことなかった人」と、自分のソーシャルグラフを時系列も次元も飛び越えて、色んな人に会えた!!!という喜びがありました。すごい。

スピーカーズディナー

今回は、とても光栄なことに提出したプロポーザルを採択していただき。
イベント前日に、「スピーカーズディナー」という粋な企画をスタッフの方々が提供してくれていました。登壇者とスタッフで集まってワイワイする会です。
さて前日だろコレどーしよ・・とも思ったものの、折角の名誉(だと思っている)なので、参加しない手はないか!と申し込んでみました。

過去にどこかで見かけた話としては「地方から登壇しに来た人が、前泊して、夜ただ1人で何もせずに過ごす・・・というのが回避できて嬉しかった!」みたいなエピソードがあり、感心していたものです。
そういう意味では、「会場から電車使って30分強で移動できるし」な身の自分は、はて・・・?とも思ったのですが。

で、終えてみて、想像していた以上に良かった楽しかった!
登壇どころかPHPカンファレンス自体が初めて〜〜というところから、少し「味方が増えた」ような心地を覚えました。
知ってる顔・1回でも話したことのある声があるというのは、凄い安心感を与えてくれます。安心感はそのままパワーとモチベーションになり。
前述の「新卒で働いていた会社」の人と出会ったのも、この回。何年前だ?めっちゃ久しぶりで、覚えていただいていることが光栄でした。実際、一緒に働いていた期間など3週間にも満たないので。(いや、あっちからしてみたら、git blameしたらコッチの名前は嫌というほど出てきているのでしょうが・・・・)

そして、何より印象に残ったのが、スタッフの人達がとても楽しそうにしている姿。
ずっと仕込んできたイベントのいよいよ本場、その前日!ですもんね。否応なくテンション上がるもの、とは想像しています。ただ、それにしても、前向きに「明日成功させるぞ〜〜〜!」とワクワク感をモロに感じさせてくれる雰囲気、めっちゃ良かった。
イベントの成否(=来場者が楽しめるか)については、コンテンツの質も大きく左右するでしょうし、その一端を担っている自分も絶対に成功させてやりてぇ〜〜と改めて思った次第。そこまでは「自分1人の戦い」「お世話になっているPHPコミュニティにちょっとでも貢献できたら良いな」という風に考えていたのですが、それに加えて「この人達の見たがっていた世界を生み出したいな」という風に鼓舞されました。

お酒も入って「煽り」なモードもやや起動していたのかな?というのもあり、スタッフの方々の複数人が「面白いトークを期待している、なんて言ったって数多くのプロポーザルから選ばれた話ばっかりだからね!満足させてくださいね!!」とでも言わんばかりの発破をかけてきたのも印象的。なんてことないコミュニケーションの一幕に過ぎませんが、多分本当に「全てのトークに期待を持ちながら当日に向けて準備をしていた」のだろうなぁと感じるのは、そういう枝葉の発言やふるまいからだったりするものだ、と思います。

当日

働いている会社がスポンサーブースを出していたので、その設営を手伝うべく朝の内に会場入りしたりなど。
自分自身が、今の会社を知ったのはイベントでのプレゼンスが相当に大きかったので、何だか不思議だなぁなどと思っていました。

スピーカーには控室(スタッフと合同)があったり、お弁当も用意してもらえたり、「あぁこんなに手厚いのか、すごいな」と思いながら。全部期待の裏返しなんでしょうね。いつかは「そりゃそうよ、だって俺が面白い話をするんでしょ?」と思えるくらいの実力と自信を持てるようになりたいもの。今回は、自分としてはまだまだ精進せねばなぁ!!!と切に思ったので、ココらへんの御恩はこれからも含めて継続的に返していきたい・・やるぞ・・・と思います。

自身の発表とブースの手伝いがあったので、聴講できたセッションは限られるのですが、少なくとも自分が見た回は満席ばかりでした。用意してもらっているホールや会議室は、どれも結構な席数があったと思うのですが、これにキャパいっぱいまで人を流し込めるのはイベントの底力かなぁと。
理想としては、発表者や発表内容の豪腕だけでいっぱいいっぱい集客出来ればよいのでしょうけど、きっとそういう話ばかりでは無いでしょう。何で人が来るかというと、「せっかく蒲田まできたんだし、何か聞いていくか」という動機が多いのだと思います。そういう人たちを、トラックまで足を運ばせるのは、イベントの組み立て方だなぁと思うのです。「客を流す力」ですね。タイムラインの組み方や、"人(ヒト)気"の出し方や、全体としてのお祭り雰囲気の出し方や。そうしたお膳立てを諸にいただいて、登壇などさせてもらったのは、めっちゃ有り難い話だなぁ・・・と感じます。

あとイベント全体的な事で言えば、ネットワークがずっと快適だったマジで凄い。

あとは何だろ。あ、elePHPant、今年は何のご縁なのか2体目w CakeDCのものと、PHPConference Japanのもの。あとデッカイ方のelePHPantがマジでデカくて笑っていましたw しかも・・売り切れてた・・・?凄い・・w

※ツイートを見かけたので追記。 https://twitter.com/koyhoge/status/1201664880723390465?s=21

発表した内容について

ほい

まず、自分のセッションを聴いてくださった方々、本当にありがとうございました。
内容に関しては、25分で話すにはもっと絞り込んでメッセージをシャープにしないと駄目だったなぁ、洗練がたりなかった・・・と反省をしています。それでも、足を運んでくださった方に、何かしら1つでも刺さるところがあったら嬉しいのですが。大きなイベントで25分も話すのが初めてだったのですが、こんなに短いもんなのか・・・

これでも大分削ったのですけどね。いつか、削った分も含めて整えた内容を公開できたら良いなと思っています。やりたいな。
セッションで話すのを前提にしなければ、もっとガツガツと実コードいれられるので、それなりのやり方が取れると考えています。もちろん、口頭で伝えられない分、ニュアンスの伝え方や相対的に(音より文字だと)説明がまどろっこしく感じられる・・などの障壁もありますが、まぁ。

会場でお会いした方も、そうでない方も、きっと手元にComposerのソースコードをおいて、見比べながら・動かしながら資料を眺めて見るときっと面白いと思います。
その際には、Xdeug(等)を利用したステップ実行が必須だと思いますので、 COMPOSER_ALLOW_XDEBUGを指定するのをお忘れなく。

ということで、「行ってみた」ブログでした!
楽しかったの一言に尽きます、ありがとうございました!!

Connehito/cake-sentryのメジャーバージョンupを(ほぼ)終えた

在籍中に作成・公開していたOSSがある。有り難いことに他薦を受けて awesome-cakephpにもリストしていただいたり、会社として初めて公開するソフトウェアだったりと、何となくの思い入れを感じている。

tech.connehito.com

既にコネヒトからは離れているが、元々の作成主であることと他にメンテナンスをしている人(コミッタ)がいないこともあり、現CTOに自ら願い出てその後もメンテナ権限をもらっている。今のところは。

めっちゃ遅くなりましたが!

今回は、Sentry側の提供しているSDKの大幅な変更が発生したため、それに伴うアップデート作業を行った。
この変更は当初よりずっと認識していて、また数日を置かずしてIssueも立てて頂いていたものだった。

github.com

これが2月なので、ここまで実に3四半期ほどを要したことになる。 やらねば・・・と思いながら、春夏を超え秋も終わるような時期になってしまった。
個人的な話としては、2-4月くらいはコレまでの社会人生活の中でもトップに入るくらい忙しくて(物理的にも精神的にも)他に何もやる気が起きず、5月からは転職活動をしたり、また5-10月の間にはコレもまたConnehito org下になるがOSSを2本出してみたり・・などして過ごしていた*1

その合間を縫ってチマチマと進めたりもしていたのだが、「作業が困難を極めた」というよりは「自分の中で、あまりテンションが上がらなかった」というのが十分に作業に取り組めなかった原因だなぁ・・とは思うところ。
上に書いたように確かに「春くらいから今に至るまで、色々あったよね」ではあるが、一時期を除いて「平日も休日も併せて数時間程度の余裕もない」という訳ではなかったはずなので、本来であればもっと早く出したかった。

主だった変更点など

Sentry SDKについて

Upgrade sentry sdk to 2x by o0h · Pull Request #17 · Connehito/cake-sentry · GitHub

主たるスコープというか動機としては、SentryのSDKバージョンアップ。
中身を見ると「すっごい変わってるなぁ」という印象をもたらすには十分な変更であり、コレが「気が重くなる」最大の要因だったようにも思う。

Version 2.x is a complete rewrite of the existing code base. The public API has been trimmed down to a minimum.

あるいは

It has a fundamentally different concept

と書いてあるとおり。
sentry-php/UPGRADE-2.0.md at master · getsentry/sentry-php · GitHub

ただし、開発者的な見方としては、やや"古臭く"なっていたコードベースが刷新されたことで、非常に触りやすくなったのではないかな・・?という風に感じている。
これで何が変わったのか?については、気が向いたら別途まとめてみたいが。

その一環は、例えばv1とv2の ClientTest を見てみると、コードがリデザインされて色々なレイヤーで関心の分離が行われてる・・・ような雰囲気から感じ取ることも出来るのではないだろうか。

2.2.0 sentry-php/ClientTest.php at 2.2.0 · getsentry/sentry-php · GitHub

1.x sentry-php/ClientTest.php at 1.x · getsentry/sentry-php · GitHub

とはいえ、プラグイン中で「実際にSentryのSDKに触れる」部分はLogクラスから使役されるClient だけだったので、その内部構造をいじることでそれ以外の箇所への影響はシャットアウトできる。これは、当初の設計として「CakeアプリケーションからSentryにどうやって触れるのが正解かな?」というのを丁寧に観察した結果だったな、と感じてホクホクしたポイント。
歴史的な経緯として、「かつて社内で使っていたSentryインテグレーションを、プラグイン化に際して構造からリライトした」ものであり、以前の状態だったら影響範囲をここまで閉じ込められていなかったかもなーとも思う。

CakePHPの新機能へのキャッチアップ

#5 Loading with Plugin objects by o0h · Pull Request #15 · Connehito/cake-sentry · GitHub

CakeSentry自体はコネヒト社内で利用されていたモジュールをプラグイン化したものであり、そのために機構としての歴史は多少古かった。
具体的に言えば、CakePHP3.5時代に「社内プラグイン化」したコードで、3.6からの機能であるPlugin Objectsに対応していない。

↓当該のPR
Implement Plugin Classes by burzum · Pull Request #11564 · cakephp/cakephp · GitHub

これを、今後の拡張性も見据えて対応させた。 SDKの大幅な変更の次に「気が重い」と感じていたのも、この「なんか凄そうな変更が入っているなぁ」と思っていた点。
結果的に、調べてみたらそこまで大げさな改修作業は必要ではなかったが。
まぁ、漠然と「どっかでやらないとな〜」と思っている事柄に対して「やらなきゃいけない新しいこと」が増えるのは、ネックにはなる。

test_appの追加

Add test app for supporting easy development by o0h · Pull Request #16 · Connehito/cake-sentry · GitHub

ここまではソフトウェアの機能としての「新しい変更点」だったが、これは「保守を簡単にするための追加点」となる。

改修作業に着手し難かった大きな要因として、「手元で簡単に動かせる状況になかった」ことが上げられる。
当然ながら自分のローカルに作業用の環境は用意していたのだが、 issue#10を貰った時には既に「久々すぎて、どう動かしていたか覚えてねぇ」状態だった。
これは思い出すまでが「遠い」し、何なら思い出しただけで「一仕事した、少し満足」となりがちなので困る!

ということで、docker-compose付きで test_app をレポジトリに突っ込んだ。
こうしたら、もうcloneしてからワンコマンドで直ぐに動かせるわけで、「どうやって動作確認しようか」というのは瞬殺で解決ですよ。

とりわけプラグイン単体だと「実際にどう動いてるの?」をイメージしづらい類のソフトでもあるので、簡単に目検でend-to-endな動作確認が出来るのは良いのでは、と思う。

CI周り

Improve ci by o0h · Pull Request #19 · Connehito/cake-sentry · GitHub

CI周りの改修も行った。
CakePHPの最新は現状では3.8だが、サポートバージョンを3.6+としている。
「3.6にある機能だけを使っている!」つもりではあるが、4.xに向けてのdeprecationも多く行われているので、「最新版を使った時にどう動くか」も継続的インテグレーションとして保証しておきたいな・・・という気持ちがあった。
というか、これはCIではなくて手動でやるのはキツい(退屈で複雑)。
ひとまず、「CIが緑になっていれば3.6+で動く」という安心材料になる状態に持ってこれたのは、今後の気安さを考える上でも良い材料になると思う。

この作業自体は、他のOSSに投げたdiffを参考にしながら比較的スムーズに出来たのかな?と思う。

ついでにphp7.4サポートを入れたり、phpstanのレベル強化&対象拡大等も行っている。

今後: 本リリースまでと、その後

testや環境構築系の確認、docs系の内容を見たり。またコード上の些細な整備やリファクタを行ってから、masterにマージして2.0.0-stableをリリースする予定。
作業的にもそこまで時間かかる内容ではないし、ここまで持ってきた以上は熱が冷めない内にやりきってしまう。
本当はCakeFestまでにはどうにか出したいなー、とは思っていたのだけど・・・・

残念なことに自分の係る環境でSentryをゴリゴリ使っているサービスがないので、十分にドッグフーディングが出来ていなそうな点が結構な心残り。
折角のOSSなので様々なフィードバックをいただければ・・とは願っているが、無責任なリリースを行うのとは全く別な話なので、心理的な引っ掛かりポイントだ。
何となくのイメージとして、2.0.3くらいまでは細かいサイクルで修正を重ねていけたら良いけどなぁと思う。もちろん、「品質的に何も問題なかった」という結果が得られたら、それが最もだが・・・・

それと併せつつやりたいこととしては、定期実行で「ちゃんとSentryのAPIを叩けているのか?」というE2Eテストを入れたいなぁという想いが暫く前からずっとある。
test_appを入れたのは、そういうところも見据えている。
実際のアプリ上で -> エラーを起こしてみて -> その後にSentryのAPI経由でデータを取得し -> 送ったつもりのデータがちゃんと受信されているかな?
という内容を、CI上で回せると良い。
これはTravisでもいいしGitHub Actionsでもいいかなーというところ。これを週1とか月1で実施して、動作性を保証できれば安心感が加速しそうなので・・・
また、今回のような大改修を入れる場合でも、「結果が正しい」というのをリアルに問うことができるようになるので、良さそう。Cake4公開までにやっちゃいたいかな〜

*1:とはいえ、公開された内の1つについては、暫く前から作業を進めていたものを大詰めした感じだけども