ローカル開発環境のセットアップの手伝いをしていて$ docker compose ps してもらった結果と、自分の手元の $ docker-compose ps の結果では表示項目の様子が違うことに気がついた。
version 1 はこういうかんじで
$ docker-compose ps Name Command State Ports ----------------------------------------------------------
version 2 はこういう感じ。
$ docker compose ps NAME COMMAND SERVICE STATUS PORTS
サービス名が表示されるのはわかりやすい。
StateがSTATUSに変わった意図はわからない。似てるけど表示されうる内容は違う。
手元で docker-compose の version 1 をいまだに使ってたけど、version 2 はすでに generally avaibaleらしいので、今後はversion2 を使うようにします。
GitHubではリポジトリを clone するとき HTTPS または SSH でやる方法と、GitHub CLI(gh) を使う方法で選べるようになっている。
どの方法でも認証が必要ではあるが、認証の方法が違う。
自分でやるときは最近は gh でやってる。
GitHub CLI を使用してコマンド ラインで GitHub に対して認証を行う場合は、個人用アクセス トークンの生成をスキップして、代わりに Web ブラウザー経由で認証できます https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token
とのこと。昔なのでそうだったか覚えてはないけどそうらしい。
gh が楽なのでは。ghインストールする必要はあるが、ghの便利なコマンドも使えるし。
チームの新メンバーのセットアップの話を聞いていて思った。gh便利だし、公式なので安心してみんな使ってほしい。デザイナーとかエンジニア以外もgithub使うので、gh 使ってもらうとサポートも楽になりそう。
ちなみに gh で登録すると remote の origin は https になる。
popIn Aladdin SEを買った。
シーリングライトの位置と壁からの距離を測ると popIn Aladdin 2やAnker Nebula Novaだと投影サイズが大きすぎたから。2mで画面サイズが70型相当。
適当に満足度を評価するとハード4/5、ソフト4/5、値段5/5、デザイン5/5 で合計 18/20 点ぐらい。つまり、今の所かなり満足している。
ソフトウェア開発の現場で心理的安全性を高めるためにどうしたらいいか、ここ最近考えている。
「心理的安全性を高めましょう」と号令をかけるだけで高められるものでもない。もしチームのリーダーやマネージャーが、チームの新人に向かって「心理的安全性をもっと高めないとだめじゃないか」と指摘するようなことがあったら滅茶苦茶だ。そこまで滅茶苦茶ではなくとも、現実では似たようなことは起こりうるのかもしれない。
わからないことを聞きましょう、意見があったら言いましょうと言いながら、聞きづらい環境をつくったり、意見にとりあってくれなかったり。それはダブルバインドだから、当事者はかなり辛い。
属人的な解決方法はわりとすぐに思いつく。基礎的な質問をしてもバカにされないというようなことを示すために、率先して基礎的な質問するとか。そういうこともやればいいと思うけど、個人の頑張り以外の工夫もほしい。
人数を少なくするというのは１つの手だと思う。普通の人は1000人の前で話すのと、数人と話すのでは数人の方が話しやすいと思う。ソフトウェア開発チームでも同じで、20人のミーティングで言いにくいことも4,5人のミーティングだと言いやすいということはありそう。
あと思いついたのは、プロジェクトやチームの状態をチェックする立場の人が、心理的安全性に関するチェック項目を持つというのはあっていいと思う。自分はそういう立場じゃないから知らないけど、そういうことは一般的にはやられてるのかな。心理的安全性が低いとわかったところでなにかテコ入れする方法がなければ意味はないけど。
ソフトウェア開発をしていると、他の人のコードや設計のレビューをすることが頻繁にある。これまでコードレビューや設計レビューというと、他の人の判断にケチをつけるようで心理的負担があった。最近は考え方が変わって、レビューに対する心理的負担は減っている。
少し前に『NOISE 上: 組織はなぜ判断を誤るのか?』という本を読んだ。この本では人間の判断には、専門家であってもばらつきがあるということが言われていた。それがノイズと本の中で言われているものだ。アメリカの裁判で、判事によって量刑のばらつきがあること、誕生日だったり、気温が暑かったり、そう言ったものでも判断の傾向が変わることなどが書かれていた。
ソフトウェアエンジニアがしている判断も、きっと似たようなノイズが含まれている。それは人間の性質としてしょうがないのかもしれない。だからレビューで複数の人間が独立に判断をする。違う意見になった時にはその中間を取ることによって、少しでもノイズを減らすことができる。レビューにそういう役割があると考えると気が楽になった。
能力があるソフトウェアエンジニアでもその日に忙しくて時間がなかったり、勘違いしやすい情報を目にしていたり、いろんなことがあって判断はぶれる。「結局のところみんな多少はブレているんだ」と思うと、ぶれてる判断を重ね合わせてなるべくぶれてない判断にしようという気持ちになる。
論理的に一方が明確に間違っていて、一方が正しいという場合もあるので必ずしも中間を取るのは正解ではないが、現実の仕事には白か黒かではなく、グレーのグラデーションのどのあたりが正解か、というような判断が多いので有効な考え方だと思う。
ちなみに下巻の『NOISE 下: 組織はなぜ判断を誤るのか?』は読んでないのでこれから読みます。Audibleで聞いていて、最近下巻が聴き放題の対象になったので。
GraphQLスキーマの具体的の利便性はおいておいて、スキーマが表すグラフの形をみてきれいということは可能なのだろうかと考えていた。
GraphQLにはQuery型という特権的な型がある、APIを拡張するたびに、どんどんQueryのフィールドを追加していってるけど、これは仕方がないことのなのかと考えたのが発端だ。
Query --> A Query --> B Query --> C
という感じでQueryからA,B,Cという型へのフィールドをはやしている。フィールドがグラフのエッジだ。
上のグラフの代わりに、以下のグラフを考えた。
Query --> A Query --> B B --> C
というふうに、Query --> Cのかわりに B --> C のほうが、グラフの形がきれいなのでは、と考えた。
感覚的に、グラフの次数(各頂点に接続する辺の数)の偏りが小さい方が感覚的にきれいなグラフに見えそうというだけだ。
逆に、上のグラフのほうがCまで最短経路が短いわけだからきれいなグラフだと言える気もする。
具体的なスキーマを考えたとき、もし Query --> C が
type Query { c(b_name: String!): C }
というフィールドでbと関係のあるCをとってきたいというときには、B --> C のほうがよいと言えないだろうか。
実装のことを考えると Query --> B --> C よりも Query --> C のほうがパフォーマンスがいいからそうしたいというケースもありそうだ。そうなるとスキーマ設計から実装を分けて考えるのは不可能になり、それは本当にいいのだろうかと悩む。
上のグラフにC --> Bを足すと、サイクルができる。
Query --> A Query --> B B --> C C --> B
サイクルがあると、B --> C --> B --> C ... という無限に辿れそうだからよくなさそうな感じはする。しかし実際のサーバではネストの深さの制限をすることが可能なので問題にはならなそうだ。
サイクルの数だったらスキーマから数えることは可能だろうなと思ったが、あまり意味はなさそうだ。
最近はたまにSwitchやPCでゲームをしる。面白いゲームにも出会うこともあるけど、ほとんどクリアできてない。諦めが早いので明確なクリアがあるゲームに向いてない性格なのかもしれない。
マインクラフト、アンダーテイル、Outer Wilds 全部好きなのにどれもクリアできてない。
マイクラは別にエンダードラゴン倒さなくても楽しめればOKな気がするけど、YouTubeで他の人がそこまで行っているのを見るといつか自分でもそこまでやりたいと思ってしまう。
Undertale アズゴアが倒せなくてやめた。
Outer Wilds プレイする間隔が開くと操作方法忘れてしまう。
クリアできたのはゼルダの伝説ブレスオブザワイルドとHadesくらい。
ブレワイは丁寧に進めていけばラスボス攻略の難易度が高くないので、ゲーム苦手な人でもできるようにうまいこと難易度設定ができている気がする。
Hadesは操作がシンプルで一直線なのがいい。運の要素もあるし、何度もやればそのうち1回ぐらい勝てると思う。
プレイ時間が長いのはもはや無理なのかも。
