HsbtDiary

■ 決め方の話

勤務先の中の話に限らず、OSS の開発でも生活のなにかでも生きてる限りは人間は決断の連続で、牛乳を買いにコンビニに行くかどうか、Prime Day でガジェットを買うかどうかも全て決断である。

で、自分の決め方のパターンとしては以下のようなことが多い

• 決める事を決める
  • 今から牛乳を買いに行くか
  • 秋に開催される技術イベントにスポンサーするかどうか
• 決め方(評価関数)を決める
  • 雨が降っておらず、冷蔵庫に牛乳がないなら買いに行く
  • 開催時期、スポンサー費用、プラン、ベネフィット、今期の残予算、方針、実施による効果見込み、担当リソースなどそれぞれについて、「これが、こうだったらスポンサーする」「全部満たしていればスポンサーする」など。
• 決めるためのインプットを集める
  • 窓の外を見る、冷蔵庫を見る
  • スポンサーの場合は構成要素全部を把握する
• 決め方とインプットがあれば自然と決まる

決め方の決め方の決め方は...とかは必要なら無限ループすればいいけど、人々はそんなに暇ではないので決める事と決め方、については役職上位者がエイッと決めてもいいし、前例を踏襲してもいいし、サイコロで決めていいし多数決でもよい。

ただ、多くの場合、決めることはチームや個人、組織の内外から issue として自明に決まる事が多く、決め方はほとんどの場合は「それはそう」というものばかりなので、「それはそう」とならないものについては、勉強をして決め方の手段を増やして関係者間で「それで」となるようにディスカッションをする。

決める、ってのはたかだかこれだけのことなのだけど、決め方が実は「評価関数はわからないが部長が決定する」なのに、自分たちが何かをできると勘違いをしてあれこれ動いていたり、評価関数に入れるインプットが集まり切ってないのに集まったと思って決めてしまった結果「そういえばさあ」とかなってちゃぶ台返しがあるとか、そういうのが散見される。集まってないなら集まってないけど、評価関数からこれを抜きましょうという話をするだけである。

あとは、エンジニアが自明でしょということを経営層が理解してくれない、みたいな話にまで飛び火させると、そもそも評価関数が違うのに同じインプットを入れて、「何もわかってない!」みたいな独り相撲をするのもよくある話なので、そこは評価関数のすり合わせをするしか無い。

決めたあとに失敗したり成功したり、した時に何か、とかできるだけ成功するものを選びたい、みたいな話は決め方とは別の話なのでここでは省略。各自頑張りましょう。

■ USB4互換の L字 延長ケーブルを買った

Amazon の Prime Day で買うものないなあと wishlist を眺めていたら、セール対象ではないけどポイント還元基準のために買っておくか、と USB4 互換の L 字延長ケーブルを買った。

Anker の有線アダプタの Type-C 側ケーブルが短くてテーブルの上に置かざるを得なかったので、これで全部机の下に追いやってすっきりできる。

USB4 L字 延長ケーブル、直角 90度【40Gbps高速転送 100w急速充電 8K@60Hz映像出力】 USB 4.0 アルミタイプ Type C 延長コード 、thunderbolt 3/4との互換性あり iMac、MacBook Pro/Air、Dell/HP Dock、XPS、Intel NUC等Type-C機種対応 在宅勤務支援 (0.6m, グレー)
-
-
￥2,199

■ Ruby 開発者会議 7 月

今月から自分がホストとなって開催。事前にある程度眺めていたので後は Matz や成瀬さん、akr さんなどと議論をするってのが主な内容。

https://bugs.ruby-lang.org/issues/19722

今回はまじでやらないとな、という Ruby 3.3 向けの bundled gems どうしましょうかについて実際に Gemfile に書かなくても require できるという PoC を作った上でどうするのが

• Ruby 開発者にとって嬉しい
• ユーザーにとっても嬉しい

というのを両立できるんでしょうかね、というのを議論した、つもり。で、最終的には $LOAD_PATH をいじる方法は諦めて、

• defautl gems を require した時に、それが来年 bundled gems になる、というものの場合は Gemfile 追加しろと警告する
• 上記のうち、直接 require しているわけではなく、ライブラリが更に依存している、というようなものは gemspec に追加しろ、author に知らせろ、と警告する(できるの?)
• 過去に bundled gems になったもののうち、多く使われているであろう、というようなものについては LoadError の追加情報として上記2つと同じように警告する

というのを Ruby 3.3 で頑張って用意して、3.4 で改めて default gems を bundled gems にしましょうという結論に達した。仕事の仕方が変わったこともあって、自分の中でのタイムスケールが1年単位ではなくて2-3年単位になったのも大きくて、より便利になる人の数が多いであろう選択肢を選ぶことができるようになったのは大きい気がする。

後は上の警告機能を8月中に作れるかどうかだなあ。頑張ろう。