（Rustの話です）言語実装しているとどうやってもRcだらけになるんだけど、一般にRcは遅い（そうは言っても、普通のBoxに加えて参照カウントをしてるだけだと思うけど、それだけでそんなに遅いの？）と言われているし不安になるが、パフォーマンスは後回しという鉄則があるので...。 でも言語だと、これはどうやってもRcを多様することになるとしか思えない...。 ということをXで喋ると怖い人から「指摘」が飛んでくるので怖いのでできないのですが...。 まあまずはリライトを終わらせることかな...。前もそんなだったな...。
mruby/edgeの書き直しをしているのだが、気まぐれでcopilotを有効にしてみた。OSSなので堂々と有効にできて便利。
これで、たとえば `op_move` を再実装しようと補完させてみたら一発でこれが出た。
あと、サンプルコードを動かそうと思って。これは今はまだmrubyのバイナリを直接食わせられないので、構造体に置き換えないといけないんだけど、その置き換えもコメントから空気を読んでしてくれた。
VMの実装とかボイラープレート的なコードが続くので（マジで）、ありがたいというほかないかもしれない...。
しかしRubyだとイマイチな補完だった記憶があるのと、昔会社でGoの補完をGeminiにお願いしたらマジで普通にイマイチだった（Geminiに日本語で質問した方がよかった）ので、この手のAI補完を信じていなかったのだが、意見を覆しますね...。 RustとかC++のようなコードタイプ量が多い言語ではものすごく有効感がある。なお前職はパテントとかも取っててライセンスに厳しかったため、契約していないCopilotは使えなかった。GoもCopilotならだいぶ生産性が上げられてた予感。 あとCでも明らかに有効と思うんだが、Rubyコミッタとか、関係者はみんな使ってるんかなあ？ まあAIの生成したライセンスを気にして有効にできないか（少なくとも大っぴらに言いづらいかもしれない）。
ザ・モデルを早々に読み終えてしまった。値段の割にページ数あったけど素早く読み終えた。
さて、今の僕の肩書きは「プロダクトエンジニア」である。この単語に関しては、有名らしいけど、JiraのSherif Mansourさんの記事を置いておこう。
シニアなエンジニアがなんでもやる人間になりがちな潮流は昔からあったが、あるブログ記事によれば、プロダクトエンジニアはフルスタックエンジニアと違って、個別の技術要素までは深く踏み込まず、ユーザ体験やマーケティングなどユーザフェイシングに近いところ、そしてドメイン知識に注力すべきとのこと。 とはいえ僕はそうは思わず、ユーザフェイシングなところもしっかりやり、個別の技術要素もちゃんとやるべきかなと思う。全部やるぞ！！１ というやつ。 そう思うのは、まず、Sherifの言うところのProduct Engineerの "Characteristics" を読んだ上できっちりやり切るには、そもそも卓越した技術力が必要なのでは？ としか思えないことが一つ。 そして、ソフトウェアの技術というのは強大な力であり、あらゆるところに陥穽があるなと思っていることもある。これは前職で強く学んだことでもある。したがって「深くなくていい」なんて中途半端な態度は取らず、リスペクトを持って自分ができるベストで深掘りや素振りをした方がいいと思う。もちろん何もかもするわけにはいかないし、トレードオフはあるだろうけど、技術が本質的に恐ろしいものだという意識とリスペクトは捨ててはいけない。 さらに言えば技術自体も第一級の関心ごとであり続けるべきだと思う。AIでもWebAssemblyでもRubyでもコンテナでもなんでもいいが、一晩語れる技術分野は自分でも持ち続けたいし、たとえば一緒に働くにしてもそういう人がいいなと思う。僕は、所謂おたく的とも言える、そういう何かの分野を一点突破する情熱に共感するし、その情熱が非連続なプロダクトの進化を生み出す鍵だと信じているため。 したがって、僕は今まで通り気になる技術をちゃんと深掘りしつつ、ユーザの観察やドメインの深掘りも興味深くやっていこうと思う。
プロダクトエンジニアは、今までの僕のエンジニアとしての動きから見ると、非常に苦手なムーブであることは間違いない。 だけど、苦手だからこそ気になるしやってやりたい。 一方で、前職でインフラエンジニアとして鍛えられた能力（非公開の往時の発表でも言ったけど）がかなり役立つとも思っている。ロジカルにストーリーを通すこと、まず計測すること、小さく出すこと、出したものをちゃんと観察すること、異常にはとにかく最初に反応すること、作り切ること、など...。 だから今こそできるかもと言う気持ちはある。