先月は、これを付け始めてから初めて「何もなかった1ヵ月」になってしまったのが何だか今の自分の状況を物語っているようで象徴的なものを感じる・・・
Release Fix unhandling event · Connehito/cake-sentry · GitHub
ずっと出せていなかったやつ・・・いろいろな問題が絡んでいて、それらをすべて取っ払う必要があったので、触る->予想してないところでつまずく -> 詰まる -> テンション下がる・・ -> 時間が経ってから再開、みたいなサイクルになってしまい変に時間がかかった！！
Release Support for CakePHP4 · Connehito/cakephp-master-replica · GitHub
こっちも「だそうだそうと思って遅れてたやつ」、cake4対応のPRもらってから丁度1ヵ月が経過・・・
=> 登壇後のエントリー #phperkaigi に参加してきました (day1) - 大好き！にちようび
「登壇しました」な話は昨日書きました
ので、色々な感想などは終了後に書きますので の部分です。
公開用に資料も整えています現在。
多くの人が既に語られていますが、とても「参加者同士の交流が多い」イベントだったなぁ〜と思います。
「Twitterとかソーシャル上で見かけた事がある」人と絡めた率が今までで1番高かった気がする、トレーディングカード効果だな。凄い #phperkaigi
— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2020年2月11日
楽しませていただきました！
去年が勿体ない感すごかったので、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参加で、この規模で喋るの初めて(高校の時に全校の前で喋ったことはある・・・)だったような気もするのだけど、その時に「凄くやりやすいなぁ」と感じた思い出。長谷川さんのMCと、それに呼応して会場の空気も暖かいのが本当に大きい。
それは今回も健在だったなぁーと思います。「初めて登壇するならPHPerKaigiが良い」というのは、個人的にも思う所*2。
ぺちぱーかいぎのLT、今年も温かい雰囲気に溢れていて素敵だった #PHPerKaigi
— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2020年2月10日
そして例によって、初めて発表する〜〜とは思えない上手な人や練られた内容が多いな、と思いました 💨
day1がルーキーズLT、day2が(ルーキーズでない)LTということで、「これday1大丈夫なのかな」とか思ったけど、全く「普通のLT」と遜色ない感じになっていたなーという感想
今回のイベントの中で「お、ソースコード見てみたいな！！」という、具体的な気になりを持って帰れたのでホクホクしております。 やはり「コードから得る学び」というのはデケェので・・・！
このイベント全体を通して、郡山さんとお話を出来たのは最も良かったことの内の1つだなぁ。
自分の発表の後の質疑応答でフィードバックというか「こういうのもあるよ！」というのをご紹介いただき、「CakePHP3とDIをつなぎ込んでいる例」があることを知りました。
それがpiping-bag。
発表の中で「CakePHP4.1でコンテナ来るはず」というのに言及した事がキッカケで頂いた声ですね。
Cake自体は「PSR-11: Container interface を採用する」という方針になるのかと思うので、どうなるんだろうな。この記事とか参考にしてみよう。もしくはphpleague/containerになるのかな。
何にせよ、CakePHP/Ray.DIのコアメンバー・作者同士のコミュニケーションを取りながら書かれている〜ということで、参考になるものが多そう。また、「ライブラリ自体はCakePHP本体的には別のものを採用する」となったとしても、「CakePHPの中にDIをどう協調させるか」みたいな部分でのアイディアが組み込まれていると思うので、その点を見たい。
というかネーミングがお洒落すぎでは🍵
ちなみに名前のピピンバッグはCakeを作るときにクリームを”
— Akihito Koriyama (@koriym) 2020年2月10日
注入”する道具で流石ホセさんセンスが良いです。
で、もう1つ教えてもらったのが、郡山さんが「お礼みたいなものも兼ねて」作ってみたというコチラ。
github.com
先のものとは逆に、「CakePHPのORMを使ってみた」例。
まっとうにDIを使ったことが無いから習作欲しいな〜と思っていた矢先なので、かつ「CakeのORMなら分かるわ！」というのがあるので、コレ参考にして何か作ってみようかなーという気持ち。
【PHPerKaigi2020】ぼくのかんがえたさいつよQueryBuilder - Speaker Deckで扱われていた題材。
だいぶ強そうなタイトル・・・と思いながら発表を聞いていたら、しっかりとコンセプトを持って、チャレンジングに開発をしているんだなぁと感じました。
「堅牢性」「再利用性」みたいなところにこだわっている印象を受けたので、中身みてみたいな〜と思っている次第
「めちゃくちゃ作り込んで完成させるぞ！」みたいな時間は恐らくなかったんじゃなかろうか・・とは推察しつつも、自分の観測範囲にいる「強い」phperのコードが見られるの貴重だな、という。そしたら見たくなりますよね！！
たくさん聞かせて貰った中で、とりわけ印象に残ったものを。
ただ、個人的には「10分や20分の時間の中で、なにか1つ印象に残る言葉があったら成功なのではないかなぁ・・」という気持ちもあるので、発表中で「残ったフレーズ」を中心に振り返る次第
(順不同です！
トータルで見て、とても「カラーの濃い」イベントだな〜と思います！
3回目なのに変化していって攻めてるの凄いな〜とも。
また来年も開催されることを祈りつつ！！
*1:ツールとしては使いたいけど，「会社」な意識を持ち込むのが嫌でして
*2:参加者の方の、この辺りのトピックに絞った記事も: https://tsukahara-lbk.hatenablog.com/entry/2020/02/12/152435
https://phperkaigi.jp/2020/ に行ってまいりまして。
プロポーザル出したら採択していただけたので、自分も30分枠で喋ってきました。
前夜祭(day-0)については参加を見送って、登壇準備等に費やしておりました・・
そのおかげもあって「発表用」と「公開用」の2タイプを用意できそうな兆しがあるので、ちょっと遅らせてupさせてください。
その代わりに・・・って事でもないですが、主旨をテキストに起こしてまとめてみます。
(簡単にまとめます、って言おうとしたけど30分枠の話なのでそこそこの分量になりました😇)
色々な感想などは終了後に書きますので(iwillblog)、この記事は「発表した内容の掻い摘み」と「Twitterで拾った感想・声に絡んで見る」というものです。 会場にてバタバタと書いているので、見直しとかは後ほどやりますが、ご感想・ご質問・ツッコミなどあったら呟いていただけると！
@deprecated の付与や E_USER_DEPRECATEDの活用。このイベントには前回も参加させていただいて、発表内容に対してフィードバックを送れるオンラインシステムを提供してくれているのは大好きな点の1つです。5分間のLTでしたが、色々な声をもらって嬉しいものでした。
それともう1つ、「この時間帯のツイートを見る」が出来ることですね！(冒頭のキャプチャを参照！！)
折角ご感想をいただいているので、リアクションしてみたいと思います。
普段、CakePHP使わないから「CakePHPの進化から読み解く、PHPフレームワークの“今”っぽさ」を聞いて雰囲気のアップデートをする試み #PHPerKaigi #b
— 山岡広幸 | Hiroyuki Yamaoka (@hiro_y) 2020年2月10日
当初は「CakePHPの設計がどうなったか」みたいな話をしようと思っていたのですが、内容を詰め始めたら「そこら辺は一切触れる余裕無さそうだな・・」となりました🙇♂️
今おそらく「クリーンに作ること」のもたらす価値〜みたいなのが再発見されてきつつあるのかな？という雰囲気は感じていて、その観点に対して「CakePHPのような、縛りの強いフレームワークはどうなのか」というのは、トピックになるのかなぁと思っています。
本トーク中で「コードの寿命」というのを強調していたので、例えば「FWの死によってアプリケーションが身動き取れなくなう」というのはリスクとして挙げられそうです。に対して、(実現できれば)クリーンアーキテクチャは処方箋になりそうかも・・・・？
と思うのですが、「寿命」というのは、「手前」にも伸ばせる事ができると思っていて、「悩みを少なくして、オーバーヘッドも少なくして」作り始める・動かし始めるというのは強烈な価値だと思います。 ので、「レールを敷く」ようなフレームワークは好物です。
CakePHPは、3.x/4.xになっても「道を示してくれる」力を保ちながら、「パーツを交換することはしやすくなった」状態だと思っています。ふわっとした言い方・・・
一応、CakePHP3をガッツリ使っていたのは前職時代になりますが、その当時は「CakePHPが足かせになっている」と感じたことはなかったです。
レガシーコードだけで自分が思うんは「セキュリティ的に欠陥かあるコード」が思い浮かぶ。モダンではないけど生存させれる。#phperkaigi #b
— おつじ (@w_o2z) 2020年2月10日
これもめちゃくちゃ大事な視点だよな！！と思いました。
そのためにも「(言語やFWの)セキュリティアップデートを迅速に行える状態を保つ」のも必要そうかもな、と感じました。
(何かポジショントーク的な話の展開の仕方になったぞ)
パッチとか新しいの出たらガンガン適用していこうぜ！そのために普段から備えておこうぜ！！となると、テストコードやCI/CD環境の充実も重要になってきそう。ココらへんもまた、「未来に近い場所に居続ける」努力なのかもなぁと思った次第です
')' が一個足りてないｗ #PHPerKaigi #b
— どぅーあき (@do_aki) 2020年2月10日
コード写してた時間は短かったはずなんですが、このツイート見てビビってましたw
レガシーとかそういう次元じゃない・・・😇
資料公開時には直します！！
#PHPerKaigi #b ただ機能を正しく使えなければ意味がないけどね。
— げんえい☕ (@gennei) 2020年2月10日
そうなんですよ、これは最低限かつ最重要なポイントですよね！！
「なんとなくカッコ良さそう」が「モダン」じゃねーぞ、と思います。
例えばPHP話でいうと、7.0から入った null合体演算子は便利で「使えそう」な場面も多いのですが、乱用しすぎるとリスクになりそうです。
「定義したつもりの変数(やプロパティ)」をウッカリ混入してしまうことになります。
ので、「既存コードを、新しいやり方で、短く書き換えられそう」な時でも、「手段と目的を履き違えるな」というのは言い続ける必要がありそう。
#PHPerKaigi #b 『パーフェクトPHP』10年前なのか。
— げんえい☕ (@gennei) 2020年2月10日
パーフェクトPHP は10年前 www #PHPerKaigi #b
— どぅーあき (@do_aki) 2020年2月10日
資料作成中に調べていて、「もう10年前！」と個人的に驚いたので言及した話。
今でも読むに値する話が詰まった、素晴らしい本だと思っています。そのため自分としては「今でもおすすめしたい」のですが、確かに「書き方が古い」部分もあるだろうな、って思うと悩ましい・・・
PHPの「中級者になるための」みたいな入門書、決定版がほしい。
こういった "言語の進化の流れ" って、 一つの言語だけ見ててもあまり見えなくて、 いろんな言語や環境の影響を受けてると思ってる。 #PHPerKaigi #b
— どぅーあき (@do_aki) 2020年2月10日
これも凄い有り難い指摘だなぁ〜と思っています！！
触れていなかったのは、発表枠の時間的な問題と、自分の見識の浅さの両面からです。
例えば,PHPのyieldはPythonのジェネレータに影響を受けていますし(PHP: rfc:generatorsのFurther resources等を見ると面白いです)、「CakePHPはRuby on Railsの」「Composerはnpmの」影響を受けている〜〜っていうのが、何よりの証左な気がします。ちょっと毛色は違いますが「PHP7はHackの」とか。
ということで、他言語や他文化圏も含めて流れを感じ取れたら、武器な気がします。とりわけPHPは、キャラクター的に他言語の影響を受けやすい印象があるんですが、どうなんですかねー
CakePHP 2→3 のときは大規模な変更を「断絶」という言葉を使って失敗だと認識し、
— おかしょい@3/21 Laravel JP Conference 来てね (@okashoi) 2020年2月10日
3 → 4 には軟着陸を仕込んだ#PHPerKaigi #b
※あとで展開する資料には参考文献をのせます
元lead developerであるMark Storyさんの発表から引用したものです。
CakePHP - The Road Ahead
ここで「CakePHP3の時どうだったのか」が語られているので、ご興味がありましたら読んでみていただけると。
OSSとしての進化、CakePHP 3から4にどう軟着陸できるようにするか。2から3への「断絶」を鑑みての。deprecatedをたくさん用意して、後方互換性を保ちつつ整理されたコードに。 #PHPerKaigi #b
— 山岡広幸 | Hiroyuki Yamaoka (@hiro_y) 2020年2月10日
去年のCakeFest(※CakePHP4の正式リリース直前)でのMark Storyさんの発表において、「4.xに移行するにはどうすればいいですか？」という説明の中で使われたスライドがコレですからねw
実際どのくらいdeprecated付けられたんだろう。後で数えてみよう
※ 今回の僕のトークに興味を持ってくれた方には面白がってもらえると思うのでオススメです！
具体例でいうと、「setter/getterの分離」みたいなのが実施されました。
( $a>value($v) をdeprecatedにして、 $a->getValue()と$a->setValue()を提供)
これは「コードの可読性を上げる(for human, for 静的解析)」ためのイシューといえますが、急に破棄されたらアプリケーションが死滅しかねないなぁというAPIなので、廃止予告を出してもらえて助かりました。CHANGELOGや移行ガイドを見ると、3.6~3.8時代にかけて、様々な箇所で「setter/getter分離」ポリシーを拡大適用していった様子が感じ取れるかと思います。
Rectorって初耳。後で調べておこう #phperkaigi #b
— のりぃ (@m_norii) 2020年2月10日
ちなみに、地味に私も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
> CakePHP は FIG メンバー
— おかしょい@3/21 Laravel JP Conference 来てね (@okashoi) 2020年2月10日
たしかに、そうだった。
これにより PHP コミュニティの資産を活用できる、と。#PHPerKaigi #b
ここ、ニュアンス結構ムズいんですけどね。
トーク後に呟いてた補足的な私見です。
FIGさいこ〜PSRはいいぞ〜〜〜みたいなのが、どこまで信頼できるかは割とシビアに見ても良いかもな？という気もしてる。正直どうなっていくのか読めん。
— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2020年2月10日
個人的にはFIGの活動素晴らしいし、流行って欲しいし応援したいんですけど。
で、「強い人達が集まって良いものを作ってくれる」というところで、自分でオラオラするよりは信頼できるヒントがある・・という事で参考にしています。
他方で、↓でも触れたことがありますが、「必ずしもどうなん」みたいな話もある〜というのも理解できます。
そんな感じなので、 「PSRが標準で、絶対だ！」ということはないぞ というのは、周りに勘違いしている人がいたら教えてあげてください・・・という気持ち。
(この記事のURLを共有するだけで良さそう PSRの誤解 - Qiita
ということで、「取り急ぎお返事」みたいなやつでした！ 「反応してもらってるし自分の意見を返してぇ〜〜」って思いつつ、でも引用ツイートとかしたくねーな、って思いからこのタイミングでブログを書いてみたフシがあります。
では、引き続き PHPerKaigiです・・・！
気が向いた時に「Cake縛りブログ」みたいのをやっていますので、何か「気になる！」とか「他の人どうしてるのか知りてぇ」みたいな話があったら、適当にIssueを立ててみてもらえると喜びます！必ずしも、全て拾えたりはしないと思いますが、自分の知識のアップデートしつつ・・
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を指定するのをお忘れなく。
ということで、「行ってみた」ブログでした！
楽しかったの一言に尽きます、ありがとうございました！！
在籍中に作成・公開していたOSSがある。有り難いことに他薦を受けて awesome-cakephpにもリストしていただいたり、会社として初めて公開するソフトウェアだったりと、何となくの思い入れを感じている。
既にコネヒトからは離れているが、元々の作成主であることと他にメンテナンスをしている人(コミッタ)がいないこともあり、現CTOに自ら願い出てその後もメンテナ権限をもらっている。今のところは。
今回は、Sentry側の提供しているSDKの大幅な変更が発生したため、それに伴うアップデート作業を行った。
この変更は当初よりずっと認識していて、また数日を置かずしてIssueも立てて頂いていたものだった。
これが2月なので、ここまで実に3四半期ほどを要したことになる。 やらねば・・・と思いながら、春夏を超え秋も終わるような時期になってしまった。
個人的な話としては、2-4月くらいはコレまでの社会人生活の中でもトップに入るくらい忙しくて(物理的にも精神的にも)他に何もやる気が起きず、5月からは転職活動をしたり、また5-10月の間にはコレもまたConnehito org下になるがOSSを2本出してみたり・・などして過ごしていた*1。
その合間を縫ってチマチマと進めたりもしていたのだが、「作業が困難を極めた」というよりは「自分の中で、あまりテンションが上がらなかった」というのが十分に作業に取り組めなかった原因だなぁ・・とは思うところ。
上に書いたように確かに「春くらいから今に至るまで、色々あったよね」ではあるが、一時期を除いて「平日も休日も併せて数時間程度の余裕もない」という訳ではなかったはずなので、本来であればもっと早く出したかった。
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インテグレーションを、プラグイン化に際して構造からリライトした」ものであり、以前の状態だったら影響範囲をここまで閉じ込められていなかったかもなーとも思う。
#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の大幅な変更の次に「気が重い」と感じていたのも、この「なんか凄そうな変更が入っているなぁ」と思っていた点。
結果的に、調べてみたらそこまで大げさな改修作業は必要ではなかったが。
まぁ、漠然と「どっかでやらないとな〜」と思っている事柄に対して「やらなきゃいけない新しいこと」が増えるのは、ネックにはなる。
ここまではソフトウェアの機能としての「新しい変更点」だったが、これは「保守を簡単にするための追加点」となる。
改修作業に着手し難かった大きな要因として、「手元で簡単に動かせる状況になかった」ことが上げられる。
当然ながら自分のローカルに作業用の環境は用意していたのだが、 issue#10を貰った時には既に「久々すぎて、どう動かしていたか覚えてねぇ」状態だった。
これは思い出すまでが「遠い」し、何なら思い出しただけで「一仕事した、少し満足」となりがちなので困る！
ということで、docker-compose付きで test_app をレポジトリに突っ込んだ。
こうしたら、もうcloneしてからワンコマンドで直ぐに動かせるわけで、「どうやって動作確認しようか」というのは瞬殺で解決ですよ。
とりわけプラグイン単体だと「実際にどう動いてるの？」をイメージしづらい類のソフトでもあるので、簡単に目検でend-to-endな動作確認が出来るのは良いのでは、と思う。
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つについては、暫く前から作業を進めていたものを大詰めした感じだけども